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Subj :  EMPLOYMENT  OF  OPEN  ARCHITECTURE  CONTRACT  GUIDEBOOK 


Ref:  (a)  OA  Contract  Guidebook,  Ver  2.0,  April  2010 

Enel:  (1)  Improvements  in  version  2.0 

(2)  Acknowledgments  OA  Contract  Guidebook  Use 

1.  Purpose .  To  update  direction  to  PEO  IWS  Program  Managers 
(PMs)  and  Contracting  Officers  on  the  use  of  reference  (a) . 


2.  Information. 


a.  In  April  2010,  Version  2.0  of  the  Open  Architecture  (OA) 
Contract  Guidebook  was  signed.  The  Government-only  version  of 
this  guide  contains  information  and  recommended  contract  language 
to  assist  PMs  and  Contracting  Officers  in  drafting  requests  and 
contracts  that  ensure  the  products  delivered  meet  the  Navy's 
standards  for  OA  development. 

b.  A  'Statement  A"  version  of  the  OA  Contract  Guidebook  is 
accessible  at  the  OA  website  (https : //acc . dau . mi 1/NOAGui debook) 
to  allow  potential  solicitations  insight  into  the  Navy's  OA 
principles  and  goals,  without  the  sensitive  portions  contained  in 
the  government-only  version. 

c.  The  language  in  this  guidebook  has  been  used  successfully 
in  several  PEO  IWS  contracts  including  Undersea  Systems,  SEWIP 
Block  2,  and  Platform  Systems  Engineering  Agent  (PSEA)  as  well  as 
in  many  contracts  throughout  the  Naval  Enterprise. 

3.  Action. 


a.  All  PEO  IWS  PMs  and  Contracting  Officers  are  directed  to 
become  familiar  with  reference  (a)  and  employ  its  principles  in 
all  future  contractual  program  development.  This  includes,  but 
is  not  limited  to,  using  its  recommended  contract  language  in 
requests  for  information,  requests  for  proposal,  and  all 
contracts.  The  Milestone  Decision  Authority  (MDA)  will  use  the 
PEO  and  PM  questions  contained  in  Appendices  2  and  3  of  the 
Guidebook  to  determine  OA-compliance  at  major  milestones. 


Subj :  REQUIREMENT  TO  EMPLOY  OPEN  ARCHITECTURE  CONTRACT  GUIDEBOOK 


b.  The  OA  Contract  Guidebook  is  for  guidance  only  and  PMs 
and  Contracting  Officers  have  the  authority  to  tailor  this 
language  as  necessary  to  meet  their  programs'  situations. 

4.  My  point  of  contact  for  this  policy  is  Mr.  Nickolas  Guertin, 
PEO  IWS  7B. 
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INTRODUCTION 


Purpose:  The  Naval  Open  Architecture  Contract  Guidebook  for  Program  Managers  is 
to  be  used  by  Program  Managers  (PMs)  who  are  incorporating  Naval  Open  Architecture 
(NOA)  principles  ( see  NOA  Requirements  Letter,  available  on  the  NOA  website  at 
https://acc.dau.mil/oa)  into  National  Security  System  (NSS)  acquisition  programs  as 
defined  by  40  U.S.C  §  11101  et  seq.  These  same  principles,  described  later  in  this 
document,  can  be  tailored  to  apply  to  the  acquisition  of  any  system  or  service,  including 
those  not  considered  to  be  “information  intensive.” 

This  Guidebook  contains  recommendations  and  is  offered  with  the  understanding  that 
individual  Program  Executive  Offices  (PEOs)  and  programs  must  have  the  flexibility  to 
adapt  its  principles  and  guidance  to  meet  their  needs.  This  document  is  intended  to 
augment,  rather  than  replace,  existing  contractual  source  materials  such  as  the  Federal 
Acquisition  Regulations  (FAR)  and  the  Defense  Federal  Acquisition  Regulation 
Supplement  (DFARS). 

There  are  a  variety  of  tools,  devices  and  resources  available  to  the  PM  when  planning  for 
and  conducting  the  acquisition  of  a  NSS  or  other  system  using  NOA  guidelines  such  as 
those  contained  in  this  Guidebook.  The  proper  use  of  these  resources  is  an  important 
element  of  the  acquisition  process  and  will  reduce  the  overall  risk  to  the  Navy  and 
Marine  Corps  by  ensuring  that  all  necessary  NOA  aspects  of  the  procurement  are 
covered.  In  addition  to  the  contract,  Request  for  Proposal  (RFP),  and  Statement  of  Work 
(SOW)  elements  that  are  discussed  in  this  Guidebook,  the  System  Specification  and  other 
system  architecture  and  design  materials  are  important.  Because  the  System 
Specification  defines  the  attributes  of  the  overall  system  to  be  developed,  it  must  describe 
how  the  technical  system  characteristics  will  contribute  to  its  openness  (such  as  its 
modularity  and  how  open  standards  will  be  incorporated).  The  System  Specification 
should  also  address  those  areas  where  future  growth  is  expected,  where  reuse  is 
envisioned,  etc.  Proper  balance  and  coordination  among  these  elements  is  important  to 
both  the  technical  design  and  the  overall  lifecycle  support  of  the  system.  Additional 
information  on  these  topics  is  included  in  the  appendices  of  this  document. 

Organization:  This  document  is  divided  into  five  chapters  containing  suggested 
language  for  RFP  Sections  C,  H,  L  and  M,  and  Award  Fee  Plans.  This  material  can  be 
tailored  for  use  in  the  specific  phase  of  an  acquisition  program.  It  can  also  be  tailored  for 
use  in  Contract  Modifications.  Appendix  1  contains  suggested  NOA-related  Data  Item 
Descriptions  (DIDs)  for  use  in  preparing  the  Contract  Data  Requirements  List  (CDRL) 
and  for  identifying  other  contractual  deliverables.  Appendices  2  and  3  are  checklists  to 
assist  the  Program  Manager  to  better  understand  the  business  and  technical  aspects  of 
NOA.  Appendices  4  and  5  address  Data  Markings  and  Open  Source  Software  (OSS). 
Appendix  6  contains  a  Glossary  of  Terms. 

Providing  Comments  and  Feedback:  Development  and  maintenance  of  this  Guidebook 
is  an  interactive  process  involving  the  “build-test-build”  method,  each  on  a  roughly 
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biennial  release.  These  releases  will  incorporate  community  inputs  and  address  topics 
that  emerge  from  the  Naval  Enterprise’s  experience  from  implementing  NOA. 

Therefore,  PEO  Integrated  Warfare  Systems  (IWS)  7  is  very  interested  in  comments, 
suggestions,  and  feedback.  We  are  also  very  interested  in  any  “real  world”  experiences 
you  may  have  in  using  NOA  principles  in  programs.  Comments  can  be  submitted  via 
email,  with  “Comments  on  NOA  Contract  Guidebook”  in  the  subject  line,  to 
N  avalO  A@navy.mil . 

Background:  Naval  Open  Architecture  (NOA)  is  the  confluence  of  business  and 
technical  practices  yielding  modular,  interoperable  systems  that  adhere  to  open  standards 
with  published  interfaces.  This  approach  significantly  increases  opportunities  for 
innovation  and  competition,  enables  reuse  of  components,  facilitates  rapid  technology 
insertion,  and  reduces  maintenance  constraints.  NOA  delivers  increased  warfighting 
capabilities  in  a  shorter  time  at  reduced  cost.  The  U.S.  Government’s  (“Government”) 
ability  to  acquire  at  least  Government  Purpose  Rights  (GPR)  in  technical  data  and 
computer  software  and  to  obtain  rights  in  other  intellectual  property  is  critical  to  this 
effort. 

The  Navy  and  Marine  Corps  have  adopted  OA  as  a  way  to  reduce  the  rising  cost  of  Naval 
warfare  systems  and  platforms  while  continuing  to  increase  capability  delivery  on 
shortened  demand  timelines. 

NOA  is  the  Naval  implementation  of  the  Office  of  the  Secretary  of  Defense’s  Open 
Systems  Joint  Task  Force’s  (OSJTF)  Modular  Open  System  Approach  (MOSA)  that  was 
first  introduced  in  2004.  While  MOSA  and  NOA  each  have  five  principles,  there  is  a 
synergy  between  them.  Each  Naval  Domain  may  choose  to  implement  them  in  a 
different  manner. 

NOA  allows  for  incorporating  more  commercial-off-the-shelf  (COTS)  technology  in 
warfare  systems  and  enabling  reuse  of  software  and  related  assets.  In  addition,  NOA  is 
an  enabler  of  FORCEnet,  the  operational  construct  and  architectural  framework  for  Naval 
Warfare  in  the  information  age  (see  http://www.forcenet.navy.mil).  More  importantly, 
OA  increases  competition  among  system  developers  through  the  use  of  open  standards 
and  standard,  published  interfaces.  It  also  facilitates  greater  collaboration  within  and 
across  Naval  Domains.  Individual  Domains  (Air,  Submarines,  Surface,  C4I,  Space  and 
Marine  Corps)  and  PEOs  may  opt  to  pursue  common  architectures  or  capabilities  across 
platforms;  the  NOA  principles  highlighted  in  these  materials  would  apply  to  these 
common  architectures. 

On  October  16,  2009,  acting  Assistant  Secretary  of  Defense  (Networks  &  Infonnation 
Integration)  /  DoD  Chief  Information  Officer  (CIO)  David  M.  Wennergren  promulgated  a 
memorandum  clarifying  guidance  on  Open  Source  Software  (OSS).  The  memo  stated 
that  in  “almost  all  cases,  OSS  meets  the  definition  of ‘commercial  computer  software’  ” 
and,  therefore,  should  be  given  similar  consideration  as  more  traditional  commercial 
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computer  software  when  a  program  is  looking  to  acquire  such  software.  1  This  will  allow 
the  Department  of  Navy  (DON)  to  utilize  OSS  throughout  the  enterprise  when  acquiring 
capabilities  to  meet  DON  business  and  warfighter  requirements.  As  with  any  COTS 
solution,  the  use  of  OSS  must  adhere  to  all  Federal,  DoD,  and  DON  policies  and  be  based 
on  open  standards  to  support  the  DoD’s  goals  of  net-centricity  and  interoperability.  In 
addition,  DON  commands  must  work  with  their  intellectual  property  counsel  to  ensure 
compliance  with  OSS  license  agreements. 

This  contract  language  guidance  is  designed  to  assist  PEOs,  Program  Managers,  legal, 
and  contracting  officials  in  addressing  the  technical  and  business  aspects  of  OA  in  the 
solicitation  and  award  of  Navy  and  Marine  Corps  contracts.  The  language  represents  a 
long-term  view  and  incorporates  many  of  the  principles  of  open  systems  mandated  by  the 
Department  of  Defense  (DoD)  Open  Systems  Joint  Task  Force  (OSJTF)  and  the  Office  of 
the  Secretary  of  Defense  (OSD)/Networks  &  Information  Integration  (Nil). 

Discussion:  This  Guidebook  contains  recommended  language  for  Section  C  and 
associated  Contract  Data  Requirements  Lists  (CDRLs)  of  contracts  and  Sections  L  and  M 
of  solicitations  issued  by  the  Navy  or  Marine  Corps  for  NSS  or  larger  “systems  of 
systems”  that  integrate  NSS  with  platforms  such  as  aircraft,  submarines,  land  vehicles, 
satellites  or  ships.  There  are  also  recommendations  for  language  that  can  be  incorporated 
in  Section  H  of  solicitations,  including  those  that  are  directed  at  existing  programs.  The 
tenn  “NSS”  refers  to  any  telecommunications  or  information  system  operated  by  the 
Government,  the  function,  operation,  or  use  of  which  (1)  involves  intelligence  activities; 
(2)  involves  cryptologic  activities  related  to  national  security;  (3)  involves  command  and 
control  of  military  forces;  (4)  involves  equipment  that  is  an  integral  part  of  a  weapon  or 
weapons  system;  or  (5)  is  critical  to  the  direct  fulfillment  of  military  or  intelligence 
missions,  but  excluding  any  system  that  is  to  be  used  for  administrative  and  business 
application  purposes  (including  payroll,  finance,  logistics,  and  personnel  management 
applications).2 

Sections  L  and  M  are  pre-award  documents  not  incorporated  into  the  actual  contract  but 
are  key  to  ensuring  contractor  understanding  of  and  compliance  with  OA  principles. 
Execution  of  an  effective  NOA  strategy  including  strategic  asset  reuse  must  be 
considered  from  both  a  Pre-Award  and  Post- Award  perspective.  The  language  contained 
in  this  document  should  be  tailored  to  reflect  the  program’s  phase  and  the  goals  of  the 
intended  procurement  action. 

Program  Managers  are  advised  to  use  this  recommended  language  and  other  appropriate 
technical  documents  after  detennining  the  specific  acquisition  relevance  to  the 
requirement.  Prior  to  tailoring  this  language  to  the  specific  needs  of  the  acquisition 
program,  Program  Managers  should  have  a  clear  understanding  of  NOA  principles. 
Acquisition  Programs  should  have  a  strategy  and  supporting  plan  that  addresses  an 
appropriate  (business  and  technical)  OA  end  state  and  acts  as  a  framework  for  structuring 

1  DoD  Memorandum  Clarifying  Guidance  Regarding  Open  Source  Software  (OSS), 
October  16,  2009. 

2  40  U.S.C.  §11103. 
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contract  language  that  is  consistent  with  DoD  guidance  for  interoperability,  such  as  that 
included  in  PEO  C4I’s  Net-Centric  Enterprise  Solutions  for  Interoperability  (NESI) 
V3.1.0  (available  at  http://nesipublic.spawar.navy.mil/).  The  Open  Architecture 
Assessment  Tool  (OAAT)3  (developed  by  the  Naval  Open  Architecture  Enterprise 
Team),  which  incorporates  the  Under  Secretary  of  Defense  for  Acquisition,  Technology 
and  Logistics  (USD(AT&L))  Open  Systems  Joint  Task  Force’s  (OSJTF’s)  MOSA 
PART4  tool,  should  be  used  to  formulate  an  OA  strategy.  Additionally,  the  Naval  Air 
Systems  Command  (NAVAIR)  Key  Open  Sub  Systems  (KOSS)  tool  can  be  used  to 
identify  the  components  of  a  modular  architecture  that  are  going  to  be  evolving  the  most 
over  time  and,  therefore,  should  receive  extra  OA  emphasis.5  Appendices  2  and  3  consist 
of  two  checklists  that  will  also  be  helpful  in  preparing  acquisition  materials. 

The  goal  of  maximizing  program  flexibility  to  enable  competition  and  programmatic 
course  changes  must  be  balanced  against  providing  the  contractor  enough  incentive  to 
agree  to  the  contract.  Short  duration  tasks  and  small  deliverable  quantities  provide  the 
Program  Manager  with  the  flexibility  to  shift  to  other  providers  to  obtain  better 
performance,  introduce  different  products  and  technologies,  or  when  otherwise  deemed  in 
the  best  interest  of  the  Government.  Such  mechanisms  are  not  a  substitute  for  effective 
project  and  contract  management  practices  by  the  Program,  but  can  provide  additional 
leverage  to  support  these  practices. 

Intellectual  Property  Rights  (IPR)  and  Data  Rights:  Program  Managers  are  strongly 
encouraged  to  assess  the  IPR  and  data  rights  requirements  of  their  program  and/or 
community  of  interest.6  Navy  and  Marine  Corps  Program  Managers  responsible  for 
ACAT  I  and  II  programs  are  further  advised  to  immediately  take  steps  to  incorporate  the 
requirements  of  DoD  Instruction  5000.02  dated  December  2,  2008  and  Under  Secretary 
of  Defense  (Acquisition,  Technology  and  Logistics)  Memorandum  on  Data  Management 
and  Technical  Data  Rights  dated  July  19,  2007  as  directed  by  the  Assistant  Secretary  of 
the  Navy  (Research,  Development  and  Acquisition).7  This  analysis  will  help  Program 
Managers  develop  Acquisition  Strategies  that  anticipate  potential  reuse  in  other  programs 
and  thus  guide  decisions  related  to  IPR  and  data  rights.  These  decisions  include:  (1) 
whether  these  rights  will  be  procured,  (2)  whether  it  will  be  considered  as  part  of  the 
technical  evaluation,  and/or  (3)  a  combination  of  both.  The  alternative  selected  by  the 
Program  Manager  will  drive  different  solutions  in  the  construct  of  Sections  C,  L  and  M. 

3  The  OAAT  can  be  found  in  the  “Tools”  section  of  the  Naval  OA  website  at 
https://acc.dau.mil/oa. 

4Modular  Open  System  Approach  Program  Assessment  Review  Tool. 

5  The  KOSS  tool  can  be  found  in  the  “Tools”  section  of  the  Naval  OA  website  at 
https://acc.dau.mil/oa. 

6  A  “community  of  interest”  or  COI  is  a  group  of  organizations  or  entities  having  similar 
interests  and  goals.  For  example,  Navy  COIs  can  be  along  warfare  requirements  (anti-air 
warfare  or  littoral  defense),  families  of  system  or  components  (radars  or  displays),  or 
functions  (acquisition  or  test  and  evaluation). 

7  Assistant  Secretary  of  the  Navy  (Research,  Development  and  Acquisition) 

Memorandum  on  Data  Management  and  Technical  Data  Rights  dated  September  11, 

2007. 
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The  attached  Section  L  and  M  language  provides  general  guidance  on  data  rights  while 
specifics  must  be  tailored  to  specific  programs. 

Program  Managers  (in  coordination  with  their  PEOs  and  Resource  Sponsor)  should 
develop  a  post-award  strategy  to  ensure  they  are  exercising  their  IPR  as  defined  by  the 
Federal  Acquisition  Regulations  (FAR)  and  Defense  Federal  Acquisition  Regulation 
Supplement  (DFARS).  Historically,  the  Navy  and  Marine  Corps  have  not  effectively 
exercised  or  enforced  the  intellectual  property  rights  (IPR)  procured  by  the  Government 
or  identified  by  contractors  in  their  proposals  by  not  including  effective  Contract  Data 
Requirements  Lists  (CDRLs)  and  Data  Item  Descriptions  (DIDs)  in  contracts.  The 
Statement  of  Work  (SOW)  establishes  the  product/system  development  expectations;  the 
CDRL  orders  the  delivery  of  the  data  according  to  the  SOW,  and  the  DID  describes  the 
format  and  content  of  the  data  ordered  by  the  CDRL  as  articulated  in  the  FAR  and 
DFARS.  It  is  incumbent  upon  the  Government,  in  general,  and  the  Program  Manager 
and  Contracting  Officer’s  Representative  (COR)  specifically,  to  review  each  deliverable 
and  report  unjustified/nonconforming  or  other  inappropriate  markings  on  delivered  data 
to  the  Contracting  Officer  in  order  to  ensure  the  PEO  is  able  to  take  full  advantage  of  the 
Government’s  rights.  The  Contracting  Officer,  with  the  assistance  of  counsel,  is 
responsible  for  enforcement  of  the  DFARS  provisions. 

An  overarching  concern  is  reconciling  10  U.S.C.  §  2320  section  (a)(2)(F)  “Rights  in 
Technical  Data”  requirements  with  the  proposed  evaluation  factors.  Although  the 
Government  cannot  condition  award  or  responsiveness  on  relinquishing  rights,  under  10 
U.S.C.  §  2320(a)(2)(G)(i)  and  (iii),  the  Government  can  negotiate  for  additional  rights  or, 
if  necessary,  the  development  of  alternative  sources  of  supply  and  manufacture.  Also, 
under  DFARS  227.7 103-2(b)(2)  “Acquisition  of  Technical  Data”  and  DFARS  227.7203- 
2(b)(2)  “Acquisition  of  Noncommercial  Computer  Software  and  Computer  Software 
Documentation”  the  Government  can  and  must  balance  the  original  assessment  of  the 
Government’s  data  needs  with  data  prices  contained  in  the  offer.  Furthermore,  10  U.S.C. 
§  2305(d)(4)(B)  “Contracts;  Planning,  Solicitation,  Evaluation,  and  Award  Procedures” 
states;  “[i]n  considering  offers  in  response  to  a  solicitation  requiring  proposals  described 
in  paragraph  (1)(B)  or  (2)(B),  the  head  of  an  agency  shall  base  any  evaluation  of  items 
developed  exclusively  at  private  expense  on  an  analysis  of  the  total  value,  in  terms  of 
innovative  design,  life-cycle  costs,  and  other  pertinent  factors,  of  incorporating  such 
items  in  the  system.”  Such  factors  may  include  the  IPR  specified  in  an  offer. 

As  part  of  a  best  value  analysis,  the  Government  may  consider  an  Offeror’s  willingness 
to  provide  the  Government  with  the  equivalent  of  GPR.  The  evaluation  criteria  must 
make  clear  that  the  Government  will  be  evaluating  the  costs  associated  with  an  Offeror’s 
restrictions  on  data  and  software-related  assets  that  would  be  delivered  under  the 
contract.  The  Government  will  assess  the  impact  on  costs  of  the  delivery  of:  1)  limited 
rights  (LR)  data,  2)  restricted  rights  (RR)  software,  3)  standard  licenses  in  Commercial 
computer  software  (CS)8,  or  4)  items  covered  under  DFARS  252.227-7015,  “Technical 
Data  -  Commercial  Items.”  For  example,  the  Government  will  examine  the  impact  of  LR 

8  “Firmware”  is  considered  to  be  a  category  of  “Computer  Software”  as  defined  in  the 
DFARS. 
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in  data  on  system  life  cycle  costs  (when  making  cost  assessment  keep  in  mind 
alternatives  like  use  of  form,  fit,  function,  etc.,  as  assessment  must  be  “reasonable”).  To 
avoid  an  unstated  evaluation  criteria  problem,  the  criteria  must  at  least  specify  the  relative 
importance  of  costs  associated  with  needs  set  forth  in  the  “Data  Rights  and  Patent  Rights” 
portion  of  the  solicitation,  e.g.,  life  cycle  costs  for  system.  Finally,  the  data  rights  and 
associated  markings  of  intellectual  property  -  including  releasability  statements  -  will 
impact  the  Government’s  ability  to  deposit  intellectual  property  (IP)  in  asset 
repositories/libraries  and  be  able  to  use  these  assets  in  other  systems. 

Award  Incentives:  Contract  type  is  determined  based  on  risk  of  on-time  completion  of 
the  work  to  be  performed.  For  firm  fixed-price  contracts  (regardless  of  dollar 
value),  program  managers  must  receive  Milestone  Decision  Authority  (MDA)  approval, 
which  must  be  based  on  a  business  case  analysis. 

Incentivizing  technical  excellence  in  the  program  is  an  important  aspect  of  the  program 
acquisition  strategy  and  is  usually  applied  with  award  fees  or  award  terms.  The  same 
approach  should  be  used  in  encouraging  appropriate  NOA  business  and  technical 
practices.  Award  Fee  earnings  are  briefed  to  the  highest  levels  within  corporate 
management  and  thus  have  the  added  benefit  of  reinforcing  the  importance  of  the 
Government’s  emphasis  on  technical  leadership,  planning  and  execution  with  this  group 
of  senior  leaders.  Award  fee  criteria  that  support  NOA  principles  are  an  important 
mechanism  for  encouraging  appropriate  behavior. 

The  incentive  arrangement  should  be  designed  to  motivate  contractor  perfonnance  that 
might  not  otherwise  be  emphasized  -  such  as  adoption  and  adherence  to  NOA  business 
and  technical  principles.  Award  incentives  may  be  applied  when  it  is  not  possible  to 
establish  a  predetermined  target  to  measure  desired  performance  and  are  earned  by  a 
contractor  through  an  evaluation  process  described  in  the  Award  Fee  Plan.  The 
application  of  award  fee  incentives  are  generally  associated  with  cost  contracts  and 
performance  is  evaluated  periodically  in  accordance  with  the  Award  Fee  Plan.  This 
incentive  approach  allows  the  Government  to  motivate  exceptional  contractor 
performance  considering  the  conditions  under  which  it  was  achieved,  normally  in  such 
areas  as  adherence  to  NOA  technical  tenets,  business  practices,  and  cooperative  behavior 
with  other  vendors  as  well  as  the  more  usual  quality,  timeliness,  technical  progress, 
technical  ingenuity,  and  cost-effective  management  requirements.  The  award  fee  or  term 
criteria  must  be  based  on  the  requirements  described  in  the  contract.  The  most  effective 
criteria  are  objective  in  nature.  When  possible,  criteria  should  be  expressed  in 
quantifiable  terms.  Some  NOA  technical  criteria  are  inherently  mixed  with  and 
supportive  of  NOA  business  criteria. 

The  “DoD  Guide  for  Integrating  Systems  Engineering  into  DoD  Acquisition  Contracts 
Version  1.0”  promulgated  by  the  Office  of  the  Under  Secretary  of  Defense  (OUSD)  for 
Acquisition,  Technology  and  Logistics  (AT&L)  includes  recommendations  for  including 
language  regarding  interface  design,  consideration  of  Modularity  and  Open  Systems 
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Standards  as  part  of  Evaluation  Criteria  and  proposal  content  for  System  Performance 
Specifications  that  could  be  considered  when  developing  technical  award  fee  criteria.9 


9  “DoD  Guide  for  Integrating  Systems  Engineering  into  DoD  Acquisition  Contracts 
Version  1.0,”  dated  December  11,  2006,  page  20,  Tables  3-4  and  3-5.  This  document  is 
located  at:  hUps://acc.dau.mil/CommunitvBrowscr.aspx?id=  l  27987. 
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Chapter  A:  RECOMMENDATIONS  FOR  SECTION  C 
(STATEMENT  OF  WORK)  LANGUAGE 


Section  C  of  the  Request  for  Proposal  (RFP)  and  the  resulting  contract  contains  the 
detailed  description  of  the  products  to  be  delivered  or  the  work  to  be  performed  under  the 
contract.  Section  C  typically  includes  a  Statement  of  Objectives/Statement  of  Work 
(SOO/SOW)  for  the  RFP/contract.  The  SOO  is  a  clear  and  concise  statement  that 
delineates  the  program  objectives  and  the  overall  program  approach,  including  the 
outcome  desired.  The  SOO,  along  with  the  preliminary  system  performance  specification 
(covering  the  technical  performance  requirements),  provides  Offerors  guidance  for 
proposing  a  solution  to  meet  the  user’s  needs.  An  additional  helpful  reference  is  the 
Department  of  Defense  Handbook  for  Preparation  of  Statement  of  Work  (SOW).10 

Although  the  Guidebook  was  developed  for  mixed  systems  comprised  of  hardware, 
middleware  and  software  elements,  the  recommended  language  can  be  easily  tailored  to 
reflect  hardware-  or  software-only  acquisitions. 

The  following  contains  recommended  language  for  the  SOW  included  in  Section  C  of  the 
RFP/contract. 

1.  Open  Systems  Approach  and  Goals 

The  Government  intends  to  procure  system(s)  having  an  Open  System  Architecture  and 
corresponding  components.  As  part  of  this  contract,  the  contractor  shall  define, 
document,  and  follow  an  open  systems  approach  for  using  modular  design,  standards- 
based  interfaces,  and  widely-supported  consensus-based  standards.  The  contractor  shall 
develop,  maintain,  and  use  an  open  system  management  plan  to  support  this  approach 
and  will  be  required  to  demonstrate  compliance  with  that  plan  during  all  design  reviews. 
As  part  of  an  open  system  management  plan,  the  contractor  will  be  required  to  identify  to 
the  Government  all  Commercial-Off-the-ShellTNon-development  Item  (COTS/NDI) 
components* 11,  their  functionality  and  proposed  use  in  the  system,  and  provide  copies  of 
license  agreements  related  to  the  use  of  these  components  for  Government  approval  prior 
to  use.  The  proposed  open  system  management  plan  will  be  incorporated  into  the 
contract  with  any  changes,  alterations,  and/or  modifications  requiring  Government 
approval. 


10  The  DoD  Handbook  for  Preparation  of  Statement  of  Work  (SOW)  is  available  on  the 
web  at  https://www.acqsolinc.com/mockups/7steps/library/DODhandbook.r)df. 

1 1  The  appropriate  definition  should  be  included  in  Section  C.  In  this  case,  we  define 
“component”  consistent  with  the  Institute  of  Electrical  and  Electronics  Engineers  (IEEE) 
definition  from  IEEE  Std  610. 12-1990,  “one  of  the  parts  that  make  up  a  system.  A 
component  may  be  hardware  or  software  and  may  be  subdivided  into  other  components.” 
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In  addition,  the  contractor  shall  provide  the  Government  (and/or  Government  support 
contractors)  electronic  access  to  its  integrated  development  environment  throughout  the 
tenn  of  the  contract. 

Program  Managers  should  consider  including  a  requirement  to  have  real-time  access  to 
the  Offeror’s  (or  an  associated  sub-contractor’s)  software  development  environment, 
providing  the  government  with  continuous  on-line  access  to  work  products  under 
development  commencing  at  the  start  of  work.  See  section  titled  “Data  Management  and 
Integrated  Development  Environment  (IDE)”  below.  Collaborative  tools  to  support  this 
access  must  be  adopted,  tailored,  and  applied  by  the  program  in  a  manner  consistent  with 
its  specific  requirements  and  circumstances. 

In  satisfying  the  Government’s  requirements,  the  following  system  architecture 
approach  characteristics  shall  be  utilized: 

a.  Open  Architecture  -  The  contractor  shall  develop  and  maintain  an  architecture 
that  incorporates  appropriate  considerations  for  reconfigurability,  portability, 
maintainability,  technology  insertion,  vendor  independence,  reusability, 
scalability,  interoperability,  upgradeability,  and  long-tenn  supportability  as 
required  by  the  23  DEC  2005  Office  of  the  Chief  of  Naval  Operations  (OPNAV 
N6/7)  requirements  letter.  (This  letter  is  available  at  https://acc.dau.mil/oa.) 

i.  Ensure  that  external  information  exchange  requirements  are  implemented  in  a 
standard  and  open  manner  as  part  of  this  effort.  These  actions  shall  include 
planning  that  identifies  the  contractor’s  specific  approach  to  ensuring  system 
and  interface  data  is  well-defined,  available  to  all  programs,  and  uses  a 
standards-based  tool  for  definition  within  the  context  of  the  Navy  and  Marine 
Corps  upgrade  programs.  The  contractor  shall  develop  system  upgrades  that 
ensure  that  1)  data  will  be  posted  to  shared  spaces  for  users  to  access  except 
when  limited  by  security,  policy,  or  regulations;  2)  data  shall  provide  for 
interoperability  with  many-to-many  exchanges  of  data,  and  verified  trust  and 
integrity  of  users  and  applications;  and  3)  data  shall  be  transmitted  through 
well  and  openly  defined  interfaces. 

ii.  The  contractor  shall  ensure  that  their  projects,  at  the  architectural  and 
operational  level,  continue  to  promote  the  use  of  an  open  architecture  as  well 
as  adoption  of  Net  Centric  Enterprise  Services  (NCES)  concepts.  The 
contractor  shall  assist  in  the  continuing  pursuit  of  Net-Centric/FORCEnet 
compliance.  Contractor  plans  must  comply  with  the  appropriate  and 
applicable  standards.  The  contractor  shall  ensure  that  the  program  is  capable 
of  interacting  with  the  Joint  Environment  and  DoD  Global  Information  Grid 
when  developing  applications  that  share  data  via  external  communications. 

b.  Modular,  Open  Design  -  The  contractor  shall  develop  an  architecture  that  is 
layered  and  modular  and  uses  standards-based  COTS/NDI  hardware,  operating 
systems,  and  middleware  that  all  utilize  either  non-proprietary  or  non-vendor- 
unique  key  Application  Programming  Interfaces  (APIs).  The  contractor’s  design 
approach  shall  be  applied  to  all  subsystems  and  components.  As  part  of  its  open 
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system  management  plan,  the  contractor  will  be  required,  at  a  minimum,  to 
describe  how  the  proposed  system  architecture  meets  these  goals,  including  the 
steps  taken  to  use  non-proprietary  or  non-vendor  unique  COTS  or  reusable  NDI 
components  wherever  practicable. 

•  Module  Coupling  -  The  contractor’s  design  approach  shall  result  in 
modules  that  have  minimal  dependencies  on  other  modules  (loose 
coupling),  as  evidenced  by  simple,  well-defined  interfaces  and  by  the 
absence  of  implicit  data  sharing.  The  purpose  is  to  ensure  that  any 
changes  to  one  module  will  not  necessitate  extensive  changes  to  other 
modules,  and  hence  facilitate  module  replacement  and  system 
enhancement.  The  approach  used  to  determine  the  level  of  coupling  and 
the  design  trade-off  approach  shall  be  described. 

•  Module  Cohesion  -  The  contractor’s  design  shall  result  in  modules  that 
are  characterized  by  the  singular  assignment  of  identifiable  and  discrete 
functionality  (high  cohesion).  The  purpose  is  to  ensure  that  any  changes  to 
system  behavioral  requirements  can  be  accomplished  by  changing  a 
minimum  number  of  modules  within  the  system.  The  approach  used  to 
determine  the  level  of  cohesion  and  the  design  trade-off  approach  shall  be 
described. 

c.  System  Requirements  Accountability  -  The  contractor  will  be  required  to  ensure 
that  all  system  requirements  (including  those  contained  in  the  Initial  Capabilities 
Document,  Capabilities  Development  Document,  Capabilities  Production 
Document,  and  in  this  Section  C)  are  accounted  for  through  a  demonstrated 
ability  to  trace  each  requirement  to  one  or  more  modules  that  consist  of 
components  that  are  self-contained  elements  with  well-defined,  open  and 
published  interfaces  implemented  using  open  standards. 

d.  Inter-component  Dependencies  -  The  contractor’s  design  approach  shall  result  in 
a  layered  system  design,  maximizing  software  independence  from  the  hardware, 
thereby  facilitating  technology  refresh.  The  design  shall  be  optimized  at  the 
lowest  component  level  to  minimize  inter-component  dependencies.  The  layered 
design  shall  also  isolate  the  application  software  layers  from  the  infrastructure 
software  (such  as  the  operating  system)  to  enhance  portability  and  to  facilitate 
technology  refresh.  The  design  shall  be  able  to  survive  a  change  to  the  computing 
infrastructure  with  minimal  or  no  changes  required  to  the  application  logic.  The 
interfaces  between  the  layers  shall  be  built  to  open  standards  or  available  to  the 
Government  with  at  least  Government  Purpose  Rights.  The  system  architecture 
shall  minimize  inter-component  dependencies  to  allow  components  to  be 
decoupled  and  re-used,  where  appropriate,  across  various  Naval  programs  and 
platforms. 

e.  Modular  Open  Systems  Approach  (MOSA)  -  The  contractor  shall  describe  its 
rationale  for  the  modularization  choices  made  to  generate  the  design.  The 
contractor’s  design  approach  shall  produce  a  system  that  consists  of  hierarchical 
collections  of  software  and  hardware  configuration  items  (components).  These 
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components  shall  be  of  a  size  that  supports  competitive  acquisition  as  well  as 
reuse.  The  contractor’s  design  approach  shall  emphasize  the  selection  of 
components  that  are  available  commercially  or  within  the  DoD,  to  avoid  the  need 
to  redevelop  products  that  already  exist  and  that  can  be  re-used.  The  contractor’s 
rationale  must  explicitly  address  any  tradeoffs  performed,  particularly  those  that 
compromise  the  modular  and  open  nature  of  the  system. 

f.  MOSA  Objectives  -  The  contractor  shall  specify  how  it  plans  to  use  MOSA  to 
enable  the  system  to  adapt  to  evolving  requirements  and  threats;  accelerate 
transition  from  science  and  technology  into  technology  and  deployment;  facilitate 
systems  reconfiguration  and  integration;  reduce  the  development  cycle  time  and 
total  life  cycle  cost;  maintain  continued  access  to  cutting  edge  technologies  and 
products  from  multiple  suppliers;  and  mitigate  the  risks  associated  with;  (1) 
technology  obsolescence,  (2)  being  locked  into  proprietary  or  vendor-unique 
technology,  and  (3)  reliance  on  a  single  source  of  supply  over  the  life  of  the 
system. 

g.  MOSA  Support  Plan  -  The  contractor  shall  provide  a  plan  for  supporting  the 
proposed  Modular  Open  System  Approach,  including,  but  not  limited  to,  plans  for 
integrating  the  systems  under  development  both  internally  and  externally,  a 
strategy  for  maintaining  the  currency  of  the  technology  (through  COTS  and  other 
reusable  NDI  insertions,  technology  refresh  strategies,  and  other  appropriate 
means)  and  creation  of  different  processes  necessary  to  support  MOSA  (more 
information  on  MOSA  is  available  from  the  Open  Systems  Joint  Taskforce 
(OSJTF)  at  http://www.acq.osd.mil/ositfiindex.html). 

h.  Design  Information  Documentation  -  The  contractor  shall  document  and  model 
the  system  or  component  (e.g.,  software,  hardware,  middleware)  design 
information  using  industry  standard  formats,  (e.g.,  Unified  Modeling  Language). 

It  shall  also  document  and  model  how  it  will  use  tools  that  are  capable  of 
exporting  model  information  in  a  standard  format  (e.g.,  Extensible  Markup 
Language  Metadata  Interchange  (XMI)  and  AP233/ISO  10303).  The  contractor 
shall  identify  the  proposed  standards  and  formats  to  be  used.  The  contractor  shall 
maintain  the  design  information,  including  any  models  used,  so  that  it  is  current 
with  the  as-built  system. 

i.  Technology  Insertion  -  The  contractor’s  architectural  approach  shall  support  the 
rapid  and  affordable  insertion  and  refreshment  of  technology  through  modular 
design,  the  use  of  open  standards  and  open  interfaces.  The  contractor  shall  define 
the  functional  partitioning  and  the  physical  modularity  of  the  system  to  facilitate 
future  replacement  of  specific  subsystems  and  components  without  impacting 
other  parts  of  the  system  and  to  encourage  third-party  vendor’s  participation. 

j.  Life-Cycle  Sustainability  -  The  contractor  shall  consider  use  of  COTS/NDI  and 
open  standards  to  enhance  the  system’s  life-cycle  sustainability  by  implementing 
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performance-based  logistics  (PBL)  arrangements  to  sustain  the  components 
through  their  life  cycle. 

k.  Interface  Design  and  Management  -  The  contractor  shall: 

i.  Clearly  define  and  describe  all  component  and  system  interfaces; 

ii.  Define  and  document  all  subsystem  and  configuration  item  (Cl)  level 
interfaces  to  provide  full  functional,  logical,  and  physical  specifications; 

iii.  Identify  processes  for  specifying  the  lowest  level  (i.e.  subsystem  or 
component)  at  and  below  which  it  intends  to  control  and  define  interfaces 
by  proprietary  or  vendor-unique  standards  and  the  impact  of  that  upon  its 
proposed  logistics  approach.  Interfaces  described  shall  include,  but  not  be 
limited  to,  mechanical,  electrical  (power  and  signal  wiring),  software, 
firmware,  and  hardware  interfaces; 

iv.  Identify  the  interface  and  data  exchange  standards  between  the 
component,  module  or  system  and  the  interconnectivity  or  underlying 
information  exchange  medium; 

v.  Consider  using  these  interfaces  to  support  an  overall  information 
assurance  strategy  that  implements  Information  Assurance  (IA)  Processes 
in  accordance  with  DoD  Instruction  8500.2  (dated  February  6,  2003)  and 
[Insert  any  PEO-specified  documents ]; 

vi.  If  applicable,  select  external  interfaces  from  existing  open  or  Government 
standards  with  an  emphasis  on  enterprise-level  interoperability.  The 
contractor  shall  describe  how  its  selection  of  interfaces  will  maximize  the 
ability  of  the  system  to  easily  accommodate  technology  insertion  (both 
hardware  and  software)  and  facilitate  the  insertion  of  alternative  or 
reusable  modular  system  elements; 

vii.  Describe  the  extent  that  the  change  or  configuration  management  process 
proposed  will  use  “community  of  interest”  teams  in  an  integrated  team 
approach  to  effectively  identify  how  individual  changes  impact  the 
system’s  internal  or  external  interfaces  and  information  exchange 
standards. 

l.  Treatment  of  Proprietary  or  Vendor-Unique  Elements  -  The  contractor  shall 
explain  the  use  of  proprietary,  vendor-unique  or  closed  components  or  interfaces. 
If  applicable,  the  contractor  will  define  its  process  for  identifying  and  justifying 
proprietary,  vendor-unique  or  closed  interfaces,  code  modules,  hardware, 
firmware,  or  software  to  be  used.  When  interfaces,  hardware,  firmware,  or 
modules  that  are  proprietary  or  vendor-unique  are  required,  the  contractor  shall 
demonstrate  to  the  Government  that  those  proprietary  elements  do  not  preclude  or 
hinder  other  component  or  module  developers  from  interfacing  with  or  otherwise 
developing,  replacing,  or  upgrading  open  parts  of  the  system. 

m.  Open  Business  Practices  -  The  contractor  shall  demonstrate  that  the  modularity  of 
the  system  design  promotes  the  identification  of  multiple  sources  of  supply  and/or 
repair,  and  supports  flexible  business  strategies  that  enhance  subcontractor 
competition.  The  contractor  shall  conduct  a  market  survey  to  identify  candidate 
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COTS,  proprietary,  open  source  software  (OSS)  and  other  reusable  NDI  capable 
of  achieving  the  performance  requirements  of  solutions  that  it  proposes  to  custom 
build.  The  survey  results  shall  be  provided  to  support  each  major  review.  COTS 
and  other  reusable  NDI  selection  criteria  shall  address  the  following  factors,  at  a 
minimum;  Electrostatic  Sensitive  Device  (ESD)  immunity;  Electromagnetic 
Interference/Electromagnetic  Compatibility  (EMI/EMC);  Integrated  Logistics 
Support  requirements;  safety;  reliability  consistent  with  the  environment 
described  in  the  System  Specification;  maintainability;  subsystem  perfonnance 
trade-offs;  power,  cooling,  and  physical  fonn  factors;  open  system  architecture 
break  out  compatibility;  cost;  manufacturer’s  quality  assurance  provisions;  market 
acceptability;  obsolescence;  adequacy  of  available  technical  and  intellectual 
property  data  and  re-procurement  data  rights  on  the  product;  and  merits  of  the 
software  supported  by  the  product.  Decisions  leading  to  the  selection  of  specific 
COTS,  NDI,  proprietary  or  OSS  products  should  be  supported  by  appropriate 
analysis  (e.g.  with  test  results,  architectural  suitability,  “best  value”  assessments, 
etc.). 

n.  Reuse  of  Pre-existing  or  Common  Items  -  The  contractor  shall  re-use  pre-existing 
or  common  items  unless  a  detennination  is  made  to  not  re-use.  Exceptions  to 
reuse  of  pre-existing  items  must  be  accompanied  by  justification,  such  as  cost 
(both  of  adoption  and  life  cycle  support),  schedule,  functional  and  non-functional 
performance,  etc.  The  general  objective  of  these  efforts  shall  be  the  development 
of  a  common  system  and/or  common  elements  or  components  which  meet  the 
performance  requirements  of  the  various  U.S.  Navy  or  Marine  Corps  platform 
missions,  where  commonality  offers  the  greatest  technical  and  cost  benefits. 

o.  Third  Party  Development  -  The  contractor  shall  address  how  it  will  provide  to  the 
Government  infonnation  needed  to  support  third-party  development  and  delivery 
of  competitive  alternatives  of  designs  for  software  or  other  components  or 
modules  on  an  ongoing  basis.  The  contractor  shall  provide  a  list  of  those 
proprietary,  vendor-unique  elements  that  it  requests  be  exempt  from  this  review. 

p.  Life  Cycle  Management  and  Open  Systems  -  The  contractor’s  architecture  shall 
provide  for  insertion  of  COTS  into  the  system  and  demonstrate  that  COTS, 
reusable  NDI,  and  other  components  are  logistically  supported  throughout  the  life 
cycle.  The  contractor  shall  describe  and  demonstrate  the  strategy  for  reducing 
product  or  system  and  associated  supportability  costs  through  insertion  of  COTS 
and  other  reusable  COTS  or  NDI  products.  The  contractor  shall  establish  a 
process  to  logistically  support  COTS  or  NDI  products.  The  contractor  shall 
describe  the  availability  of  commercial  repair  parts  and  repair  services,  facilities, 
and  manpower  required  for  life  cycle  support  and  demonstrate  they  are  adequate 
to  ensure  long  term  support  for  COTS  or  NDI  products.  The  contractor  shall 
provide  the  proposed  methodology  for  pass  through  of  COTS  warranties  to  the 
Government. 
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q.  Use  of  Standards  -  In  designing  the  system(s),  the  contractor  shall  use  the 
following  standards  in  descending  order  of  importance; 

•  Standards  as  specified  within  the  contract 

•  Commercial  standards 

o  Standards  developed  by  international  or  national  industry  standards 
bodies  that  have  been  widely  adopted  by  industry.  Examples  of  widely 
adopted  standards  are: 

1.  SQL  for  databases  (e.g.,  SQL  for  databases  ANSI 
ISO/IEC  9075-1,  ISO/IEC  9075-2,  ISO/IEC  9075-3, 
ISO/IEC  9075-4,  ISO/IEC  9075-5) 

2.  HTML  for  presentation  layer  (e.g.,  XML  1 .0 
www.webstandards.org) 

3.  XML  for  data  transfer 

4.  Web  Services  for  remote  system  calls 

o  Standards  adopted  by  industry  consensus-based  standard  bodies  and 
widely  adopted  in  the  market  place. 

o  De  facto  standards  (those  widely  adopted  and  supported  in  the  market 
place). 

Note:  Standards  that  are  not  specified  within  this  contract  or  that  are 
modified  must  be  submitted  to  and  approved  by  the  Government  Program 
Manager  prior  to  use. 

There  is  additional  guidance  to  Naval  acquisition  managers  intended  to  provide  improved 
visibility  into  Offeror’s  and  contractor’s  software  development  processes  to  ensure  there 
are  well-documented,  effective  software  processes  and  continuous  process  improvement 
practices  in  place  during  contract  performance.  This  guidance  and  requirements  are 
contained  in  the  Software  Process  Improvement  Initiative  (SPII)  Policy.  Mandatory  and 
discretionary  elements  of  the  SPII  Policy  are  described  in  the  policy  document.  The  SPII 
Policy  and  accompanying  documents  are  available  on  NOA  website  at 
https://acc.dau.mil/CommunityBrowser.aspx?id=180966&lang=en-US. 

Statement  of  Work  (SOW)12 

Within  the  SOW  there  shall  be  a  “Technical  Approach”  section.  This  section  describes 
the  Navy  and  Marine  Corps'  expectations  regarding  the  technical  approach  to  be  taken  by 
the  Offerors.  It  is  recommended  that  these  expectations  be  based  on  the  characteristics  of 
the  system  to  be  developed  and  not  mandate  any  specific  approach,  but  rather  define  the 
criteria  with  which  proposed  approaches  will  be  evaluated.  In  some  cases,  however, 
specific  approaches  may  be  required  based  on  Navy  and  Marine  Corps  needs  and  the 
system  to  be  acquired.  Within  the  “Technical  Approach”  section,  there  shall  be  a 
subsection  titled  “Software  Engineering  Approach,”  containing  at  a  minimum  the 
following  language: 


12 

Assistant  Secretary  of  the  Navy  (Research,  Development  and  Acquisition) ’s 
Memorandum  on  “Software  Process  Improvement  Initiative  Contract  Language,”  dated 
November  17,  2006. 
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Software  Engineering:  The  contractor  shall  define  a  software  development  approach 
appropriate  for  the  computer  software  effort  to  be  performed  under  this  solicitation.  This 
approach  shall  be  documented  in  a  Software  Development  Plan  (SDP)  (CDRL  AOOx). 
The  contractor  shall  follow  this  SDP  for  all  computer  software  to  be  developed  or 
maintained  under  this  effort. 

The  SDP  shall  define  the  Offeror's  proposed  life  cycle  model  and  the  processes  used  as  a 
part  of  that  model.  In  this  context,  the  term  “life  cycle  model”  is  as  defined  in  IEEE/EIA 
Std.  12207.0.  The  SDP  shall  describe  the  overall  life  cycle  and  shall  include  primary, 
supporting,  and  organizational  processes  based  on  the  work  content  of  this  solicitation. 

In  accordance  with  the  framework  defined  in  IEEE/EIA  Std.  12207.0,  the  SDP  shall 
define  the  processes,  the  activities  to  be  performed  as  a  part  of  the  processes,  the  tasks 
which  support  the  activities,  and  the  techniques  and  tools  to  be  used  to  perform  the  tasks. 
Because  IEEE/EIA  Std.  12207  does  not  prescribe  how  to  accomplish  this  task,  the 
Offeror  shall  provide  this  detailed  information  so  the  Navy  and  Marine  Corps  can  assess 
whether  the  Offeror’s  approach  is  viable. 

The  SDP  shall  contain  the  information  defined  by  IEEE/EIA  Std.  12207.1,  section  5.2.1 
(generic  content)  and  the  Plans  or  Procedures  in  Table  1  of  IEEE/EIA  Std.  12207.1.  In 
all  cases,  the  level  of  detail  shall  be  sufficient  to  define  all  software  development 
processes,  activities,  and  tasks  to  be  conducted.  Infonnation  provided  must  include — at 
a  minimum— specific  standards,  methods,  tools,  actions,  strategies,  and  responsibilities 
associated  with  development  and  qualification. 

Software  Code  Walkthroughs:  In  addition,  another  step  in  the  software  development 
management  process  that  supports  OA  and  can  be  included  in  Section  C  of  the  contract  is 
the  requirement  to  hold  Software  Code  Walkthroughs.  As  an  example,  this  requirement 
may  look  like  this: 

“The  contractor  shall  conduct  periodic  code  walkthroughs  during  the  development 
Phase,  as  specified  by  the  Statement  of  Work  (SOWW)  or  by  Technical 
Instruction  (TI).  Senior  technical  personnel  from  the  development  team  will 
review  the  code  and  unit  test  plans  that  have  been  developed  for  a  Technical 
Design  Specification  (TDS).  The  purpose  of  the  review  is  to  identify  that  the  code 
adheres  to  the  program’s  development  standards,  is  technically  sound,  meets  the 
design  articulated  in  the  related  TDS,  and  that  the  unit  test  plan  for  the  code  under 
review  is  documented  in  accordance  with  QA/Test  standards  as  defined.  The 
Navy  reserves  the  right  to  have  one  or  more  representatives,  on  a  not-to-interfere 
basis,  observe  any  and  all  code  walkthroughs  and  create  a  detailed  report.” 

Code  walkthroughs  will  not  be  conducted  until  the  code  has  appropriate  markings  with 
respect  to  intellectual  property  rights.  These  walkthroughs  help  support  the  OA  principle 
of  design  disclosure. 

Data  Management  and  the  Integrated  Development  Environment  (IDE):  The  IDE  is 

an  integral  tool  for  facilitating  data  management  and  design  disclosure,  including  a 
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requirement  to  maintain  an  IDE  as  part  of  contract  perfonnance  is  important  to  the 
Government’s  interests.  The  following  is  sample  contract  language  for  this  requirement: 

“The  contractor  shall  establish  and  maintain  a  secure  Integrated  Data 
Environment  (IDE)  for  hosting  all  data  used  on  or  produced  in  support  of  this 
contract,  including  cost,  schedule,  and  technical  data  and  deliverables. 

This  purpose  of  the  IDE  is  to  create  a  seamless,  collaborative  data  environment 
for  the  contractor  and  government  team  which  contains  all  pertinent  data  about 
the  project  throughout  its  development  and  delivery.  This  data  management 
program,  including  IDE  structure,  fonnat,  processes,  and  procedures,  shall  be 
documented  as  part  of  the  contract  Program  Management  Plan. 

The  contractor  shall  provide  the  Government  team  access  to  all  data  listed  in  the 
Data  Accession  List  (DAL)  by  actively  using  the  IDE.  The  DAL  shall  contain  the 
list  of  all  data  generated  in  support  of  this  contract.  Deliveries  of  data  in  addition 
to  the  IDE  shall  be  as  indicated  in  the  CDRL  attachment. 

Data  shall  be  protected  in  accordance  with  (IAW)  the  appropriate  Program 
Protection  Plans  and  Information  Assurance  guidelines.  The  Government  reserves 
the  right  to  witness  all  contractor  efforts  to  accomplish  the  Statement  of  Work 
(SOW)  requirements  and  maintains  the  right  to  comment  on  processes. 

All  products  and  data  developed  under  this  Contract  shall  be  delivered  with 
unlimited  usage  rights,  as  defined  in  Section  H,  DFARS  clause  252.227.7013, 
7014,  and  7017. 


Product  Reuse  Demonstration:  As  part  of  system  acceptance,  the  contractor  shall 
demonstrate  the  steps  necessary  to  give  third  parties,  as  directed  by  the  Government,  the 
ability  to  rebuild  the  software  for  operational  use  in  compatible  processing  hardware. 

This  effort  shall  be  comprehensive  and  require  the  contractor  to  perform  the  following 
activities: 

1 .  Inventory:  A  detailed  inventory  of  all  code  files  in  the  product  baseline  shall  be 
conducted.  This  inventory  shall  extend  to  all  third-party  software  not  delivered 
within  the  terms  of  the  contract  but  used  in  the  system  to  form  the  working 
product.  Third-party  product  descriptions  and  version  information  shall  be 
required  for  all  operating  systems,  applications,  middleware,  and  device  drivers. 

2.  Inspection:  File  headers  and  any  other  company  markings  found  in  the  source 
code  shall  be  inspected  to  ensure  clear  indication  that  the  Government  has  GPR  to 
use  the  software  delivered  in  the  contract. 

3.  Build  Procedure  Development:  A  build  procedure  shall  be  developed  in  sufficient 
detail  to  allow  a  third  party  to  recreate  the  operational  system  on  a  compatible 
processing  platfonn.  This  build  procedure  shall  address  the  results  of  the  code 
inventory  and  inspection  to  account  for  software  that  is  not  deliverable  due  to 
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proprietary  rights  limitations  such  that  the  user  can  complete  the  installation 
process. 

4.  Conduct  Demonstration:  The  contractor  shall  conduct  a  formal  demonstration  of 
the  build  process  using  the  product  baseline  software  and  approved  procedures  to 
show  the  software  can  be  successfully  ported  to  other  third-party  compatible  open 
architecture  processing  systems. 


Technical  Development  Reviews:  In  some  cases,  the  Government  may  want  to  require 
the  contractor  to  perform  Technical  Development  Reviews.  The  purpose  of  these 
reviews  includes,  but  is  not  limited  to,  observing  that  the  design  documentation  is 
complete,  complies  with  the  established  design  approach,  is  technically  sound  and  will 
satisfy  the  functional  requirements.  The  following  is  sample  contract  language  for  this 
requirement; 

Perform  Technical  Development  Reviews 

The  contractor  shall  conduct  formal  technical  reviews  as  well  as  periodic 
Technical  Development  Reviews  for  major  capability  upgrades.  The  contractor, 
in  concert  with  the  Government,  shall  develop  a  Design  Review  Plan  for  the 
conduct  of  formal  reviews,  using  agreed  upon  tailoring  of  the  Technical  Review 
Manual  (TRM)  (Attachment  J-9)  and/or  the  SEMP.  The  purpose  of  these  reviews 
is  to  observe  that  the  design  documentation  is  complete,  complies  with  the 
established  design  approach,  is  technically  sound  and  will  satisfy  the  functional 
requirements  as  defined  in  the  approved  Functional  Design  Specification 
documents.  Senior  technical  personnel  from  the  development  team  will  review 
each  design  approach  and  Technical  Design  Specification  as  it  is  completed  to 
ensure  it  has  been  properly  documented  as  defined  in  the  CDRL.  The  Navy  will 
establish  entry/exit  criteria  and  acceptance/rejection  criteria  for  each  formal 
review  and  will  document  these  criteria  in  a  Technical  Instruction  (TI).  These 
Technical  Reviews,  both  formal  and  informal,  are  to  be  scheduled  in  the  Program 
Master  Schedule  so  they  are  visible  to  the  Navy. 

Technical  Review  Objectives: 

a.  Assess  the  development  maturity  based  on  technical  development  goals,  systems 
engineering  events  and  accomplishments,  and  empirical  test  data  supporting 
progress  to  date. 

b.  Ensure  operational,  functional,  performance,  infonnation  assurance,  cost, 
schedule  requirements  and  objectives,  designs,  implementations,  technical 
performance  measurements,  and  technical  plans  are  being  tracked,  are  on 
schedule,  and  are  achievable  within  existing  programmatic  constraints. 

c.  Assess  the  system  requirements  and  allocations  to  ensure  that  requirements  are 
unambiguous,  consistent,  complete,  feasible,  verifiable,  and  traceable  to  top-level 
requirements. 

d.  Demonstrate  that  the  relationships,  interactions,  interdependencies,  and  interfaces 
between  required  items  and  externally  interfacing  items,  system  functions, 
subsystems,  and  system  elements  (including  operators  and  maintainers),  as 
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appropriate,  have  been  addressed. 

e.  Assess  the  degree  of  openness  of  the  emerging  system,  its  degree  of  Naval 
Enterprise  reuse,  and  critique  any  tradeoff  decisions  made. 

OA  Approach  to  Developing  to  a  Technical  Review: 

General  and  specific  OA  objectives  shall  be  developed  to  evaluate  the  degree  of  system 
openness  as  defined  in  the  Open  Architecture  Assessment  Tool  (OAAT)  and  activities 
defined  in  the  Open  Systems  Management  Plan  (OSMP). 

1.  Define  OA  objectives  for  each  technical  review  as  defined  in  the  System 
Engineering  Technical  Review  (SETR)  manual 

2.  Tailor  the  OA  objectives  to  what  can  be  accomplished  by  the  time  of  the  review 
and  for  which  there  is  supporting  technical  infonnation 

3.  Map  OA  objectives  to  specific  metrics  from  the  OAAT  and  the  results  of 
activities  defined  in  the  OSMP 

4.  Record  the  OA  objectives  and  the  results  of  the  metrics  and  activities  as  an  input 
to  the  technical  review 

Example  OA  Technical  Review  Objectives: 

1 .  The  OA  emphasis  for  Alternative  Systems  Review  (ASR)  is  on  innovation  and 
competition.  A  specific  focus  will  be  to  evaluate  the  degree  to  which  functionality 
and  solutions  are  drawn  from  a  diversified  range  of  large  and  small  businesses 
and  maximize  affordable  use  of  COTS/NDI. 

2.  The  OA  emphasis  for  System  Requirements  Review  (SRR)  is  on  collaboration 
and  the  accessibility  and  availability  of  data.  A  specific  focus  will  be  to  evaluate 
the  consistency  between  the  system  requirements  and  open  system  design 
considerations,  ensuring  that  the  preferred  system  solution  does  not  contain 
design  specific  solutions. 

3.  The  OA  emphasis  for  System  Functional  Review  (SFR)  is  on  enterprise 
architectures,  strategic  reuse,  and  the  potential  for  small  business  participation 
throughout  the  program  lifecycle.  A  specific  focus  will  be  to  evaluate  whether  the 
system  functional  definition  follows  modular  design  tenets  and  well-defined 
interfaces  to  effectively  manage  risks  of  obsolescence  and  dependence  upon  a 
sole  source  of  supply. 

4.  The  emphasis  of  the  OA  objectives  for  Preliminary  Design  Review  (PDR)  is  on 
the  requirements  tradeoffs  to  meet  performance.  A  specific  focus  will  be  to 
evaluate  the  degree  to  which  inter-component  dependencies  preclude  affordable 
and  lower-risk  future  open  system  capability  insertion,  which  will  drive  cycle¬ 
time  for  capability  improvements. 
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Chapter  B:  EXAMPLES  OF  SECTION  H  (SPECIAL  CONTRACT 
REQUIREMENTS)  LANGUAGE 


Section  H  of  the  Request  for  Proposal  (RFP)  and  the  resulting  contract  contains  special 
clauses  that  can  be  incorporated  into  contracts  as  appropriate.  The  following  are 
examples  taken  from  contracts  that  may  be  useful  to  Programs.  An  additional  helpful 
reference  is  the  Department  of  Defense  Handbook  for  Preparation  of  Statement  of  Work 
(SOW).13 

This  section  contains  only  recommended  guidance,  and  is  offered  with  the  understanding 
that  individual  PEOs  and  programs  can  be  flexible  in  selecting  those  items  needed  to 
meet  their  needs.  Programs  should  not  feel  that  they  need  to  address  all  of  the  items 
contained  in  these  recommendations. 

There  is  additional  guidance  to  Naval  acquisition  managers  intended  to  provide  improved 
visibility  into  Offeror’s  and  contractor’s  software  development  processes  to  ensure  there 
are  well-documented,  effective  software  processes  and  continuous  process  improvement 
practices  in  place  during  contract  performance.  This  guidance  and  requirements  are 
contained  in  the  Software  Process  Improvement  Initiative  (SPII)  Policy.  Mandatory  and 
discretionary  elements  of  the  SPII  Policy  are  described  in  the  policy  document,  which  is 
available  on  NOA  website  at: 

https://acc.dau.mil/CommunityBrowser.aspx?id=180966&lang=en-US. 


CLAUSE  H  - _ :  REQUIREMENT  FOR  AN  OPEN  SYSTEM  MANAGEMENT 

PLAN 

The  contractor  shall  submit  to  the  Government  an  Open  System  Management  Plan  as  set 
for  the  in  the  Contract  Data  Requirements  List  (CDRL).  At  a  minimum,  the  plan  shall 
address: 

Technical  Approach  and  Processes 

Open  Systems  Approach  and  Goals.  The  contractor  shall  prepare  and  submit  for 
Government  approval  its  Open  System  Management  Plan  which  shall  include  its 
approach  for  using  modular  design,  standards-based  interfaces,  and  widely-supported, 
consensus-based  standards  to  achieve  the  following  goals.  At  a  minimum,  the  plan  shall 
include: 

a.  OPNAV  OA  Requirements  -  A  detailed  description  of  the  contractor’s 
approach  for  addressing  a  system  architecture  that  incorporates 
appropriate  considerations  for  reconfigurability,  portability, 


IT 

"  The  DoD  Handbook  for  Preparation  of  Statement  of  Work  (SOW)  is  available  on  the 
web  at  https://www.acqsolinc.com/mockups/7steps/librarv/DODhandbook.pdf. 
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maintainability,  technology  insertion,  vendor  independence,  reusability, 
scalability,  interoperability,  upgradeability,  and  long-term  supportability 
as  defined  by  the  Naval  Enterprise  in  the  23  Dec  2005  Office  of  the  Chief 
of  Naval  Operations  (OPNAV)  requirement  letter. 

b.  Design  Disclosure  -  Within  the  constraints  of  contractual  data  rights,  a 
detailed  description  of  the  contractor’s  approach  to  facilitate  the  sharing  of 
system  or  component  (e.g.,  software,  hardware,  middleware)  design 
information.  The  contractor  shall  describe  how  its  design  will  be 
documented  and  modeled  using  industry  standard  formats  (e.g.,  Unified 
Modeling  Language),  and  how  it  will  use  tools  that  are  capable  of 
exporting  model  infonnation  in  a  standard  format  (e.g.,  Extensible  Markup 
Language  Metadata  Interchange  (XMI)  and  AP233/ISO  10303).  The 
Offeror  shall  identify  the  proposed  standards  and  formats  to  be  used. 

c.  Technology  Insertion  and  Refresh  -  A  detailed  description  of  how  the 
contractor’s  proposed  system  will  allow  for  rapid  and  affordable 
technology  insertion  and  refresh.  At  a  minimum,  the  contractor  shall 
describe  how  the  proposed  system  will  allow  incremental  systems 
improvement  through  upgrades  of  individual  hardware  or  software 
modules  with  newer  modular  components.  At  a  minimum,  the  description 
shall  address  how  the  contractor’s  architectural  approach  will  support  this 
requirement  including  how  components  from  third-party  providers  and 
reuse  sources  shall  be  included. 

d.  Asset  Reuse  -  A  detailed  description  of  the  steps  taken  to  reduce 
acquisition  of  duplicative  system  components  where  possible.  At  a 

minimum,  the  contractor  shall  describe  what  artifacts  from  the _ 

or  common  components  it  intends  to  use  within  its  proposed  solution. 

e.  Modular  Open  Systems  Approach  (MOSA)  -  A  detailed  description  of 
the  contractor’s  modular,  open  systems  approach.  At  a  minimum,  the 
contractor  shall  address; 

i.  Plans  for  integrating  the  systems  both  internally  and  with 
external  systems; 

ii.  The  means  for  ensuring  conformance  to  open  standards  and 
profiles  throughout  the  development  process,  as  discussed  in 
Section  C; 

iii.  A  description  of  how  the  technical  approach  ensures  having 
access  to  mature  as  well  as  the  latest  technologies  by 
establishing  a  robust,  modular,  and  evolving  architecture  based 
on  open  standards; 

iv.  A  description  of  the  strategy  for  maintaining  the  currency  of 
technology  (e.g.,  through  COTS  or  reusable  NDI  insertion, 
technology  refresh  strategies,  and  other  appropriate  means); 
and 

v.  Identification  of  processes  for; 

(1)  Isolating  functionality  through  the  use  of  modular 
design; 
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(2)  Evaluating  modular  open  system  baseline 
standards,  defining  and  updating  profiles,  and 
evaluating  and  justifying  new  or  vendor-unique 
profiles; 

(3)  Validating  implementation  conformance  to 
selected  profiles; 

(4)  Managing  application  conformance  to  selected 
profiles;  and 

(5)  Training  in  use  of  profiles. 

f.  MOSA  as  an  Enabler  of  OA  Objectives  -  A  detailed  description  of  how 
the  contractor  intends  to  use  a  modular  open  systems  approach  as  an 
enabler  to  achieve  the  following  objectives; 

i.  Adapt  to  evolving  requirements  and  threats  as  identified  by  the 
Government; 

ii.  Enhance  interoperability  and  the  ability  to  integrate  new 
capabilities  without  redesign  of  entire  systems  or  large  portions 
thereof; 

iii.  Accelerate  transition  from  science  and  technology  into  acquisition 
and  deployment; 

iv.  Facilitate  systems  reconfiguration  and  integration; 

v.  Reduce  the  development  cycle  time  and  total  life-cycle  cost; 

vi.  Maintain  continued  access  to  cutting  edge  technologies  and 
products  from  multiple  suppliers;  and 

vii.  Mitigate  the  risks  associated  with  reliance  on  a  single  source  of 
supply  over  the  life  of  the  system,  to  include,  but  not  be  limited  to, 
technology  obsolescence  and  dependence  on  proprietary  or 
vendor-unique  technology. 

g.  Life-Cycle  Supportability  -  A  detailed  description  of  how  the  contractor 
intends  to  enhance  life-cycle  supportability  by  implementing  performance- 
based  logistics  arrangements  to  sustain  the  components  through  their  life 
cycle. 

h.  Employ  a  Layered,  Modular  Architecture  -  A  detailed  description  on 
how  the  proposed  system  architecture  is  layered,  modular,  and  makes 
maximum  use  of  Commercial-Off-the-Shelf/Non-developmental  Item 
(COTS/NDI)  hardware,  operating  systems,  and  middleware  that  utilize 
non-proprietary  key  Application  Programming  Interfaces  (APIs)  whenever 
practicable. 

i.  Traceability  of  System  Requirements  -  A  detailed  description  of  the 
contractor’s  approach  for  ensuring  that  all  system  requirements  (including 
those  contained  in  the  Initial  Capabilities  Document,  Capabilities 
Development  Document,  and  in  Section  C)  are  accounted  for  through  a 
demonstrated  ability  to  trace  each  requirement  to  one  or  more  modules. 
Modules  consist  of  components  (one  of  the  parts  that  make  up  a  system 
and  may  be  hardware  and/or  software)  which  are  self-contained  elements 
with  well-defined,  standards -based  and  published  interfaces. 
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j.  Minimize  Inter-Component  Dependencies  -  A  detailed  description  of 
the  contractor’s  approach  for  designing  a  system  that,  to  the  maximum 
extent  practicable,  minimizes  inter-component  dependencies  and  allows 
components  to  be  decoupled  and  re-used,  where  appropriate,  across 
various  Naval  programs  or  replaced  by  competitive  alternatives. 

k.  Rationale  for  Modularization  Choices  -  A  detailed  description  of  the 
contractor’s  rationale  for  the  modularization  choices  made  to  generate  the 
design.  At  a  minimum,  the  rationale  shall  explicitly  address  any  tradeoffs 
performed,  particularly  those  that  compromise  the  modular  and  open 
nature  of  the  system. 

l.  Future  System  Upgrades  -  A  detailed  description  of  how  a  modular 
design  strategy  will  be  demonstrated  in  all  aspects  of  future  system 
upgrades. 

i.  In  addressing  the  specified  requirements,  the  plan,  at  a  minimum, 
must  demonstrate  how  the  modular  design  strategy  applies,  and  the 
effect  it  will  have  on  future  systems  upgrades. 

ii.  The  contractor  shall  describe  an  orderly  planned  process  to  address 
migration  of  proprietary,  vendor-unique,  or  closed  system 
equipment  or  interfaces  to  a  modular  open  systems  design  when 
technological  advances  are  available  or  when  operational 
capability  is  upgraded.  The  proprietary,  vendor-unique  or  closed 
systems  implementation  shall  also  be  reflected  in  the  contractor’s 
system  level  life  cycle  cost  estimates. 

iii.  The  modular  design  approach  shall  either  mitigate  or  partition  -  at 
the  lowest  subsystem  or  component  level  -  proprietary,  vendor- 
unique  or  closed  system  implementation  to  avoid  out-year 
supportability  issues  and  diminished  manufacturing  and  repair 
sources. 

Interface  Design  and  Management.  The  contractor  shall  describe  how  it  will  clearly 
define  component  and  system  interfaces.  At  a  minimum,  the  contractor  shall  address  the 
following; 

a.  The  contractor  shall  describe  how  it  will  define  and  document  all 

subsystem  and  configuration  item  (Cl)  level  interfaces  to  provide  fully 
functional,  physical  and  electrical  specifications. 

i.  The  contractor  shall  identify  processes  for  specifying  the  lowest 
level  (i.e.  subsystem  or  component)  at  and  below  which  it  intends 
to  control  and  define  interfaces  by  proprietary,  vendor-unique 
standards,  as  well  as  the  impact  of  those  standards  upon  the 
proposed  modularity  and  logistics  approach. 

ii.  Interfaces  described  shall  include,  but  not  be  limited  to, 
mechanical,  electrical  (e.g.,  power  and  signal  wiring),  software 
(e.g.,  API),  firmware,  and  hardware. 

iii.  The  contractor  shall  address  the  interface  and  data  exchange 
standards  between  the  component,  module  or  system  and  the 
interconnecting  or  underlying  information  exchange  medium. 
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iv.  The  contractor  shall  state  how  these  interfaces  support  an  overall 
Information  Assurance  strategy  that  provides  a  defense  in  depth  in 
accordance  with  CJCSI  3 170.0 IE  and  [Add  appropriate  PEO- 
specified  requirements ]. 

b.  The  contractor  shall  describe  how  interfaces  will  be  selected  from  existing 
open  or  Government  standards  with  emphasis  on  system-level  or 
enterprise-level  (where  applicable)  interoperability.  The  contractor  shall 
describe  how  its  selection  of  interfaces  will  maximize  the  ability  of  the 
system  to  readily  accommodate  technology  insertion  (both  hardware  and 
software)  and  facilitate  the  insertion  of  alternative  or  reusable  modular 
system  elements. 

c.  The  contractor  shall  describe  how  its  system  will  allow  for; 

i.  Quickly  interconnecting,  reconfiguring,  and  assembling  existing 
systems,  subsystems,  and  components; 

ii.  Interchanging  and  using  information,  services  and/or  physical 
items  among  components  within  a  system; 

iii.  Interchanging  and  using  information,  services  and/or  physical 
items  among  systems  within  an  integrated  architecture,  platform, 
PEO,  Community  of  Interest,  or  a  DoD  component; 

iv.  Supporting  reuse  of  software  and  the  common  use  of  components 
across  various  product  lines;  and 

v.  Transferring  a  system,  component,  or  data,  from  one  hardware  or 
software  environment  to  another. 

d.  The  contractor  shall  describe  the  degree  to  which  the  defined  interfaces 
will  support  an  Infonnation  Assurance  (IA)  strategy  that  implements  IA 
Processes  in  accordance  with  DoD  Instruction  8500.2  (dated  February  6, 
2003)  and  [ Add  appropriate  PEO-specified  requirements ]. 

e.  The  contractor  shall  describe  the  degree  to  which  proposed  interfaces  use 
defined  commercial  or  Government  standards  as  called  for  in  Section  C. 

Treatment  of  Proprietary  or  Vendor-Unique  Elements.  The  contractor  shall  justify 
any  use  of  proprietary,  vendor-unique,  or  closed  components,  including  but  not  limited 
to  COTS,  and  interfaces  in  current  or  future  designs.  The  contractor  shall  define  its 
process  for  identifying  and  justifying  proprietary,  vendor-unique  or  closed  interfaces, 
code  modules,  hardware,  firmware,  or  software  to  be  used. 

a.  The  contractor  shall  describe  how  it  will  employ  hardware  and/or 
software  partitioning  or  other  design  techniques  to  isolate  all  proprietary, 
vendor-unique  portions  of  interfaces,  hardware,  firmware  and  modules  - 
at  the  lowest  subsystem  or  component  level. 

b.  The  contractor  shall  include  documentation  to  support  the  rationale  for  a 
decision  to  integrate  proprietary,  vendor-unique  or  closed  system 
hardware  and/or  software  functions  within  the  proposed  system. 

c.  The  contractor  shall  describe  how  the  integration  of  closed  or 
proprietary,  vendor-unique  equipment,  interfaces,  data  systems  or 
functions  due  to  a  unique  or  specific  system  requirement  will  not 
preclude  or  hinder  other  component  or  module  developers  from 
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interfacing  with  or  otherwise  developing,  replacing,  or  upgrading  open 
parts  of  the  system. 

d.  The  contractor  shall  identify  and  take  steps  to  prevent  the  open  elements 
of  the  system  from  intertwining  with  proprietary  or  vendor-unique 
elements  in  a  manner  that  restricts  or  limits  the  ability  to  replace  or 
upgrade  the  open  elements  using  an  open  competitive  selection  process. 

e.  The  contractor  shall  describe  and  demonstrate  that  the  modularity  of  the 
system  design  promotes  identification  of  multiple  sources  of  supply 
and/or  repair,  and  supports  flexible  business  strategies  that  enhance  sub¬ 
contractor  competition. 

i.  The  contractor  shall  conduct  a  market  survey  to  identify  candidate 
COTS  and  other  reusable  NDI,  including  Government  IP  assets, 
capable  of  achieving  the  performance  requirements  of  solutions 
that  it  has  proposed  to  custom  build.  Sound  “market  research” 
will  help  to  identify  opportunities  to  use  COTS  or  re-use  existing 
components  and  is  called  for  by  the  OSJTF.  The  COTS  and  other 
NDI  selection  criteria  shall,  at  a  minimum,  address  the  following 
factors;  Electrostatic  Sensitive  Device  (ESD)  immunity; 
Electromagnetic  Interference/Electromagnetic  Compatibility 
(EMI/EMC);  Integrated  Logistics  Support  requirements;  Safety; 
Reliability  (to  include  the  hardware’s  designed-in  ability  to 
accommodate  such  stresses  as  electrical  power  fluctuation 
(voltage,  current,  frequency)),  temperature,  shock,  vibration, 
operating  time  (duration),  changes  in  atmospheric  pressure,  and 
humidity  consistent  with  the  environment  described  in  the  System 
Specification;  Maintainability;  Subsystem  perfonnance  trade-offs; 
Power,  cooling,  and  physical  form  factors;  Open  system 
architecture  break  out  compatibility;  Cost;  Manufacturer’s  quality 
assurance  provisions;  Market  acceptability;  Obsolescence; 
Adequacy  of  available  technical  and  intellectual  property  data  and 
reprocurement  data  rights  on  the  product;  and  Merits  of  the 
software  supported  by  the  product. 

ii.  The  Offeror  shall  identify  those  pre-existing  items  (Government  IP 
assets,  NDI,  and  COTS)  it  will  evaluate  for  reuse.  At  a  minimum, 

the  Offeror  shall  describe  what  artifacts  from  the _ it 

intends  to  use  within  its  proposed  solution.  Exceptions  to  reuse  of 
pre-existing  items  must  be  accompanied  by  justification,  such  as 
cost  (both  of  adoption  and  life  cycle  support),  schedule,  functional 
and  non-functional  performance,  etc. 

f.  The  contractor  shall  address  how  it  will  provide  information  needed  to 
support  third-party  development  and  delivery  of  competitive  alternatives 
or  designs  for  software  or  other  components  or  modules  on  an  ongoing 
basis.  This  information  may  be  used  as  part  of  peer  review  processes,  to 
support  Integrated  Product  Teams  (IPTs),  and  to  facilitate  competition  for 
component  suppliers.  The  Offeror  will  provide  a  list  of  those  proprietary 
or  vendor-unique  elements  that  it  requests  be  exempt  from  this  review. 
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Life  Cycle  Management  and  Open  Systems.  The  contractor  shall  describe  and 
demonstrate  the  strategy  for  reducing  product  or  system  and  associated  supportability 
costs  through  insertion  of  COTS  or  reusable  NDI  products. 

a.  The  contractor  shall  identify  and  demonstrate  a  strategy  to  insert  COTS 
technologies  and  other  reusable  NDI  into  the  system  and  demonstrate  that 
COTS,  other  reusable  NDI,  and  other  components  are  logistically 
supported  throughout  the  system’s  life  cycle. 

i.  The  contractor  shall  identify  specific  hardware  and  software 
elements  of  the  subsystem  designs  that  are  planned  for  COTS  and 
other  reusable  NDI  replacement  and  the  supportability  plans  for 
those  elements. 

ii.  The  contractor  shall  demonstrate  how  the  subsystem  design  allows 
for  timely  and  cost-effective  replacement  of  subsystem  elements  or 
modules.  The  COTS/NDI  selection  processes  shall  be  specifically 
addressed,  including  validation  of  those  processes. 

b.  The  contractor  shall  provide  a  description  of  processes  that  will  be 
established  and  demonstrate  that  COTS  and  other  reusable  NDI  products 
are  logistically  supported. 

c.  The  contractor  shall  describe  the  availability  of  commercial  repair  parts 
and  repair  services,  facilities  and  manpower  required  for  life  cycle  support 
and  demonstrate  that  they  are  adequate  to  ensure  long  tenn  support  for 
COTS  and  other  reusable  NDI  products.  The  Offeror  shall  provide  the 
proposed  methodology  for  pass  through  of  COTS  warranties  to  the 
Government. 


Clause  H  - _ :  EARLY  AND  OFTEN  TECHNICAL  DISCLOSURE 

The  contractor  shall  submit  a  detailed  plan  for  making  design  and  interface  infonnation 
available  as  soon  as  possible  after  it  is  defined  or  established.  The  contractor  shall 
establish  and  maintain  a  process  that  will  provide  “early  and  often”  design  disclosure 
directly  to  the  Government  or  to  third-party  contractors  via  Government-established 
access  (e.g.,  the  Naval  Sea  Systems  Command  Software/Hardware  Asset  Reuse 
Enterprise  (SHARE)  library,  its  successor,  or  other  Navy  and  Marine  Corps 
repository/library  resources)  to  in-process  design  documentation  and  computer  software. 
Access  to  this  infonnation  shall  be  supported  using  industry  standards  and  at  minimal 
cost  to  the  Government.  The  exchange  of  information  shall  be  structured  so  as  to  protect 
the  Offeror's  and  third-party  developers’  proprietary  or  vendor-unique  rights  in  the 
information.  The  plan  shall  address  how  comments  from  the  Government  and  third-party 
contractors  are  resolved.  The  plan  shall  describe  a  schedule  of  when  non-proprietary 
licenses,  source  code,  drawings,  repair  and  engineering  documentation  will  be  provided 
to  the  Government  and  third-party  contractors  at  specified  key  events  or  at  defined 
intervals. 

[Note:  Firmware  is  considered  to  be  a  category  of  Computer  Software  (CS),  as  defined 
intheDFARS.] 
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Identification  of  Open  Source  Software  (OSS)  in  contractor  Deliverable  Items 

The  following  H  Clauses  present  two  alternatives  for  addressing  the  identification  of  OSS 
in  items  delivered  to  the  Government  by  contractors.  The  first  clause  has  been  in  use  for 
several  years  and  served  as  our  original  attempt  to  help  programs  understand  the  OSS 
they  may  be  acquiring  in  their  contractor-delivered  items.  The  second  clause  is  a  recent 
update  that  we  believe  improves  upon  the  original. 


Clause  H  - _ :  Identification  of  Commercial  Technical  Data/Computer 

Software  (Including  Open  Source  Software)  Use  and  Modifications 


Commercial 
Technical 
Data/Computer 
Software  Title  and 
Version  # 

* 

If  Open 

Source 
Software, 
Open  Source 
License  and 
Version  # 

** 

Name  of 

contractor 

Delivering 

Commercial 

Software 

*** 

Technical  Use/ 

Implementing 

Approach 

If  OSS,  Was 
OSS  modified 
by  contractor? 

If  OSS  and  OSS 
was  Modified,  was 
OSS  modified  by 
incorporation  into  a 
third  party’s 
software? 

*  The  complete  title  and  version  number  of  the  Commercial  Software  should  be  listed.  If 
the  line  item  is  Open  Source  Software  that  was  downloaded  from  a  website,  the  website 
address  should  also  be  provided. 

**  The  Open  Source  Software  license  and  version  number  should  be  listed.  If  a  version 
number  is  not  available,  the  contractor  should  state  no  version  number. 

\***  Corporation,  individual,  or  other  person  as  appropriate. 

****  j[lc  contractor  should  describe  the  functionality  of  the  Commercial  (Open  Source) 
Software,  and  where  it  is  being  used  within  the  larger  computer  software  deliverable  (if 
applicable). 

*****  If  the  contractor  is  delivering  OSS,  the  contractor  should  state  whether  it  has 
modified  the  Open  Source  Software. 

******  If  the  contractor  is  delivering  OSS  that  it  has  modified,  the  contractor  should 
state  whether  the  Open  Source  Software  was  modified  by  combining  with  another  party’s 
non-open  source  software.  If  the  other  party  is  a  third  party,  the  third  party’s  non-open 
source  computer  software  may  be  licensed  with  distribution  restrictions  which  would  not 
allow  the  Government  to  accept  delivery  of  the  software  combination. 
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Clause  H  - 


:  IDENTIFICATION  AND  ASSERTION  OF 


RESTRICTIONS  ON  TECHNICAL  DATA  -COMMERCIAL  ITEM  AND 
COMMERCIAL  COMPUTER  SOFTWARE,  INCLUDING  OPEN  SOURCE 
SOFTWARE 


THIS  CLAUSE  IS  UNDERGOING  ADDITIONAL  REVIEW  and  will  be  posted  when 
the  review  is  complete 


Clause  H  -  _ :  SPECIALLY  NEGOTIATED  LICENSE  RIGHTS 

[Fill  in  based  on  the  Section  B  Data  Rights  Table.] 

1 .  The  United  States  Government  has  Special  License  Rights  in  the  Data.  Special 
License  Rights  means  the  right  to; 

(i)  Use,  modify,  reproduce,  perform,  display,  or  disclose  the  Data  within  the 
Government  without  restriction;  and 

(ii)  Release  or  disclose  the  Data  outside  the  Government  and  authorize 
persons  to  whom  the  release  or  disclosure  has  been  made  to  use,  modify, 
release,  perform,  display,  or  disclose  that  Data  for  United  Sates 
Government  Purposes. 

2.  Data,  as  used  in  this  clause,  means  all  the  information  delivered  to  the 
Government  as  required  by  CDRL. 

3.  United  States  Government  Purposes,  as  used  in  this  clause,  has  the  same 
definition  as  Government  Purpose  found  at  DFARS  252.227-7013  and  DFARS  252.227- 
7014, except 

(i)  It  does  not  include  foreign  military  sales  (FMS)  and  Foreign  Military 
Funded  (FMF),  and 

(ii)  It  does  not  include  allowing  states  and/or  local  governments  to  directly 
procure  equipments  utilizing  the  [Complete  based  on  the  program 
specifics.]  for  any  purpose  or  to  authorize  parties  other  than  the  Federal 
Government  to  do  so. 


Clause  H  - 


:  SPECIAL  PROVISIONS  FOR  THE  PURPOSE  OF 


CONFIGURATION  CONTROL;  REGARDING  RELEASE  AND  DISCLOSURE 

OF  [Complete  based  on  program  specifics.]  SOFTWARE  AND  SOFTWARE 
DOCUMENTATION 

It  is  specifically  agreed  that  software  and  software  documentation  delivered  by 
[contractor]  to  the  Government  as  required  by  this  contract  or  [Add  other  contracts  as 
appropriate.]  shall  not  be  released  or  disclosed  in  whole  or  in  part  by  [contractor],  or  by 
any  subcontractor  or  entity  acting  on  its  behalf,  to  any  entity,  for  U.S.  Department  of 
Defense  purposes,  other  than  to  the  U.S.  Government  entity  described  in  section(s)  H  to 
this  contract  without  first  providing  written  notification  to  the  contracting  officer  unless 
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such  notification  would  result  in  a  violation  of  third-party  agreements  existing  on  the  date 
of  award  of  this  contract,  in  which  case  no  notification  is  required.  Such  disclosure 
restrictions  shall  remain  in  effect  for  the  tenn  of  this  contract  and  for  six  (6)  months  [or 
other  period.']  thereafter. 

Except  as  otherwise  provided  for  above,  nothing  contained  in  this  clause  shall  be 
construed  to  limit  any  intellectual  property  rights  owned  by,  controlled  by,  or  licensed  to 
[contractor]  and  used  in  the  performance  of  this  contract. 


Clause  H  - _ :  SPECIAL  DEVELOPMENT  LIMITATION  PROVISIONS 

a)  While  the  Government  understands  that  the  initial  software  development  of  [the 
specific  program  version  X]  will  be  performed  on  [platform ],  [contractor]  specifically 
agrees  that  the  completion  of  the  [the  specific  program  version  X]  software  shall  be 
successfully  tested  on  a(n)  [specific  platform]  product  prior  to  delivery,  unless  otherwise 
approved  by  the  Contracting  Officer. 

b)  [contractor]  specifically  agrees  that  the  [the  specific  program  version  X]  developed 
under  this  contract  shall  be  developed  on  a(n)  [specific  platform]  product,  unless 
otherwise  approved  by  the  Contracting  Officer. 

c)  Notwithstanding  the  foregoing,  [contractor]  shall  not  be  prohibited  under  this  contract 
from  performing  design  and  development  on,  or  making  modification  or  enhancements  to 
the  software  or  documentation  provided  under  this  contract  if  such  effort  is  performed 
outside  of  this  contract.  To  the  extent  that  [contractor]  designs  or  develops  or  makes 
modification  to  such  software  or  software  documentation  that  is  not  prohibited  by  this 
clause,  [contractor]  shall  only  use  the  name  or  term  [program  name]  when  followed  by 
“[contractor]  Rev  XX”  [For  “XX”  insert  applicable  revision  number]  when  referring  to 
these  versions  in  order  to  distinguish  these  versions  of  the  software  from  the  [program 
name]  versions  delivered  under  this  contract  and  being  maintained  by  the  Government. 
The  purpose  of  these  restrictions  in  use  of  the  name  or  term  [program  name]  is  to  assure 
that  the  Government  maintains  configuration  control  of  the  [program  artifacts]  resulting 
from  this  contract. 
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Chapter  C:  RECOMMENDATIONS  FOR  SECTION  L 
(INSTRUCTIONS  TO  OFFERORS)  LANGUAGE 


Although  the  Guidebook  was  developed  for  mixed  systems  comprised  of  hardware, 
middleware  and  software  elements,  the  recommended  language  can  be  easily  tailored  to 
reflect  hardware-  or  software-only  acquisitions. 

There  is  additional  guidance  to  Naval  acquisition  managers  intended  to  provide  improved 
visibility  into  Offeror’s  and  contractor’s  software  development  processes  to  ensure  there 
are  well-documented,  effective  software  processes  and  continuous  process  improvement 
practices  in  place  during  contract  performance.  The  guidance  and  requirements  are 
contained  in  the  Software  Process  Improvement  Initiative  (SPII)  Policy.  Mandatory  and 
discretionary  elements  of  the  SPII  Policy  are  described  in  the  policy  document,  which  is 
available  along  with  other  SPII  documents  on  the  NOA  website  at; 
https://acc.dau.mil/CommunityBrowser.aspx?id=180966&lang=en-US. 

Naval  Open  Architecture  Guidance 

Factor  (  ):  Technical  Approach  and  Processes 

The  Offeror  shall  describe  its  proposed  Naval  Open  Architecture  (NOA)  technical 
approach  and  processes  to  be  employed  in  performing  this  contract.  At  a  minimum,  the 
Offeror  shall  describe  its  OA  technical  approach  and  processes  in  the  following  areas: 
Subfactor  1.  Open  Systems  Approach  and  Goals.  The  Offeror  shall  describe  its  open 
systems  approach  for  using  modular  design,  standards-based  interfaces,  and  widely- 
supported,  consensus-based  standards  to  achieve  the  following  goals.  At  a  minimum,  the 
Offeror  shall  provide  the  following  as  part  of  its  proposal: 

a.  Address  OPNAV  OA  Requirements  -  A  detailed  description  of  the 
Offeror’s  approach  for  addressing  a  system  architecture  that  incorporates 
appropriate  considerations  for  reconfigurability,  portability,  maintainability, 
technology  insertion,  vendor  independence,  reusability,  scalability, 
interoperability,  upgradeability,  and  long-term  supportability  as  called  for 
by  the  23  Dec  2005  Office  of  the  Chief  of  Naval  Operations  (OPNAV) 
requirement  letter,  which  is  available  at  https://acc.dau.mil/oa. 

b.  Design  Disclosure  -  Within  the  constraints  of  contractual  data  rights,  a 
detailed  description  of  the  Offeror’s  approach  to  facilitate  the  sharing  of 
system  or  component  (e.g.,  software,  hardware,  middleware)  design 
information  in  support  of  peer  reviews  and  the  incremental  development 
process.  [  “Design  Disclosure  ”  can  be  enabled  through  a  variety  of 
mechanisms  including  keeping  data,  code  and  design  artifacts  in  a 
repository  either  maintained  by  or  overseen  by  the  Government  (such  as  the 
Surface  Domain  ’s  SHARE);  providing  the  artifacts  electronically  upon 
requests  made  via  the  Government;  or  allowing  requesting  parties  to  obtain 
them  directly  from  the  source  firm  through  a  process  involving  review  and 
approval  from  the  Government.  Each  program  has  the  flexibility  to 
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establish  the  most  appropriate  mechanism  for  its  specific  needs;  with  a  goal 
of  establishing  a  process  that  is  both  cost-effective  and  responsive  to 
requests.]  The  Offeror  shall  describe  how  its  design  will  be  documented 
and  modeled  using  industry  standard  formats  (e.g.,  Unified  Modeling 
Language),  and  how  it  will  use  tools  that  are  capable  of  exporting  model 
infonnation  in  a  standard  format  (e.g.,  Extensible  Markup  Language 
Metadata  Interchange  (XMI)  and  AP233/ISO  10303).  The  Offeror  shall 
identify  the  proposed  standards  and  fonnats  to  be  used. 

c.  Technology  Insertion  and  Refresh  -  A  detailed  description  of  how  the 
Offeror’s  proposed  system  will  allow  for  rapid  and  affordable  technology 
insertion  and  refresh.  For  example,  the  Offeror  should  describe  how  the 
proposed  system  will  allow  incremental  systems  improvement  through 
upgrades  of  individual  hardware  or  software  modules  with  newer  modular 
components.  At  a  minimum,  the  description  shall  address  how  the  Offeror’s 
architectural  approach  will  support  this  requirement  including  how 
components  from  third-party  providers  and  reuse  sources  shall  be  included. 

d.  Asset  Reuse  -  A  detailed  description  of  the  steps  taken  to  reduce  acquisition 
of  duplicative  system  components  where  possible.  At  a  minimum,  the 

Offeror  shall  describe  what  artifacts  from  the _ or  common 

components  it  intends  to  use  within  its  proposed  solution. 

e.  Modular  Open  Systems  Approach  (MOSA)  -  A  detailed  description  of 
the  Offeror’s  modular  open  systems  approach.  At  a  minimum,  the  Offeror 
shall  address; 

i.  Plans  for  integrating  the  systems  both  internally  and  with  external 
systems; 

ii.  The  means  for  ensuring  conformance  to  open  standards  and 
profdes,  as  discussed  in  Section  C,  throughout  the  development 
process; 

iii.  A  description  of  how  the  technical  approach  ensures  having  access 
to  mature  as  well  as  the  latest  technologies  by  establishing  a 
robust,  modular,  and  evolving  architecture  based  on  open 
standards; 

iv.  A  description  of  the  strategy  for  maintaining  the  currency  of 
technology  (e.g.,  through  COTS  or  reusable  NDI  insertion, 
technology  refresh  strategies,  and  other  appropriate  means);  and 

v.  Identification  of  processes  for; 

(1)  Isolating  functionality  through  the  use  of  modular 
design; 

(2)  Evaluating  modular  open  system  baseline  standards, 
defining  and  updating  profiles,  and  evaluating  and 
justifying  new  or  vendor-unique  profiles; 

(3)  Validating  implementation  conformance  to  selected 
profiles; 

(4)  Managing  application  conformance  to  selected 
profiles;  and 

(5)  Training  in  use  of  profiles. 
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f.  MOSA  as  an  Enabler  of  OA  Objectives  -  A  detailed  description  of  how 
the  Offeror  intends  to  use  a  modular  open  systems  approach  as  an  enabler  to 
achieve  the  following  objectives; 

i.  Adapt  to  evolving  requirements  and  threats  as  identified  by  the 
Government; 

ii.  Enhance  interoperability  and  the  ability  to  integrate  new 
capabilities  without  redesign  of  entire  systems  or  large  portions 
thereof; 

iii.  Accelerate  transition  from  science  and  technology  into  acquisition 
and  deployment; 

iv.  Facilitate  systems  reconfiguration  and  integration; 

v.  Reduce  the  development  cycle  time  and  total  life-cycle  cost; 

vi.  Maintain  continued  access  to  cutting  edge  technologies  and 
products  from  multiple  suppliers;  and 

vii.  Mitigate  the  risks  associated  with  reliance  on  a  single  source  of 
supply  over  the  life  of  the  system,  to  include,  but  be  not  limited  to, 
technology  obsolescence  and  dependence  on  proprietary  or 
vendor-unique  technology. 

g.  Life-cycle  Supportability  -  A  detailed  description  of  how  the  Offeror 
intends  to  enhance  life-cycle  supportability  by  implementing  performance- 
based  logistics  arrangements  to  sustain  the  components  through  their  life 
cycle. 

h.  Employ  a  Layered  Modular  Architecture  -  A  detailed  description  on  how 
the  proposed  system  architecture  is  layered,  modular,  and  makes  maximum 
use  of  Commercial-Off-the-Shelf/Non-Developmental  Item  (COTS/NDI) 
hardware,  operating  systems,  and  middleware  that  utilize  non-proprietary 
key  Application  Programming  Interfaces  (APIs)  whenever  practicable. 

i.  Traceability  of  System  Requirements  -  A  detailed  description  of  the 
Offeror’s  approach  for  ensuring  that  all  system  requirements  (including 
those  contained  in  the  Initial  Capabilities  Document,  Capabilities 
Development  Document,  and  in  Section  C  of  this  Solicitation)  are  accounted 
for  through  a  demonstrated  ability  to  trace  each  requirement  to  one  or  more 
modules.  Modules  consist  of  components  (one  of  the  parts  that  make  up  a 
system  and  may  be  hardware  and/or  software)  which  are  self-contained 
elements  with  well-defined,  standards-based  and  published  interfaces. 

j.  Minimize  Inter-Component  Dependencies  -  A  detailed  description  of  the 
Offeror’s  approach  for  designing  a  system  that,  to  the  maximum  extent 
practicable,  minimizes  inter-component  dependencies  and  allows 
components  to  be  decoupled  and  re-used,  where  appropriate,  across  various 
Naval  programs  or  replaced  by  competitive  alternatives. 

k.  Rationale  for  Modularization  Choices  -  A  detailed  description  of  the 
Offeror’s  rationale  for  the  modularization  choices  made  to  generate  the 
design.  At  a  minimum,  the  rationale  shall  explicitly  address  any  tradeoffs 
performed,  particularly  those  that  compromise  the  modular  and  open  nature 
of  the  system. 
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1.  Future  System  Upgrades  -  A  detailed  description  of  how  a  modular  design 
strategy  will  be  demonstrated  in  all  aspects  of  future  system  upgrades. 

i.  In  addressing  the  specified  requirements,  the  proposal,  at  a 
minimum,  must  demonstrate  how  the  modular  design  strategy 
applies,  and  the  effect  it  will  have  on  future  systems  upgrades. 

ii.  The  proposal  shall  describe  an  orderly  planned  process  to  address 
migration  of  proprietary,  vendor-unique,  or  closed  system 
equipment  or  interfaces  to  a  modular  open  systems  design  when 
technological  advances  are  available  or  when  operational 
capability  is  upgraded.  The  proprietary,  vendor-unique  or  closed 
systems  implementation  shall  also  be  reflected  in  the  Offeror’s 
system  level  life  cycle  cost  estimates. 

iii.  The  modular  design  approach  shall  either  mitigate  or  partition  -  at 
the  lowest  subsystem  or  component  level  -  proprietary,  vendor- 
unique  or  closed  system  implementation  to  avoid  out-year 
supportability  issues  and  diminished  manufacturing  and  repair 
sources. 

Subfactor  2.  Interface  Design  and  Management.  The  Offeror  shall  describe  how  it 
will  clearly  define  component  and  system  interfaces.  At  a  minimum,  the  Offeror  shall 
address  the  following; 

a.  The  Offeror  shall  describe  how  it  will  define  and  document  all 
subsystem  and  configuration  item  (Cl)  level  interfaces  to  provide  fully 
functional,  physical  and  electrical  specifications. 

i.  The  Offeror  shall  identify  processes  for  specifying  the  lowest  level 
(i.e.  subsystem  or  component)  at  and  below  which  it  intends  to  control 
and  define  interfaces  by  proprietary,  vendor-unique  standards,  as  well 
as  the  impact  of  those  standards  upon  the  proposed  modularity  and 
logistics  approach. 

ii.  Interfaces  described  shall  include,  but  not  be  limited  to, 
mechanical,  electrical  (power  and  signal  wiring),  software,  firmware, 
and  hardware. 

iii.  The  Offeror  shall  address  the  interface  and  data  exchange 
standards  between  the  component,  module  or  system  and  the 
interconnecting  or  underlying  information  exchange  medium. 

iv.  The  Offeror  shall  state  how  these  interfaces  support  an  overall 
Information  Assurance  strategy  that  provides  a  defense  in  depth  in 
accordance  with  CJCSI  3170.01E. 

b.  The  Offeror  shall  describe  how  interfaces  will  be  selected  from  existing 
open  or  Government  standards  with  emphasis  on  system-level  or 
enterprise-level  (where  applicable)  interoperability.  The  Offeror  shall 
describe  how  its  selection  of  interfaces  will  maximize  the  ability  of  the 
system  to  readily  accommodate  technology  insertion  (both  hardware  and 
software)  and  facilitate  the  insertion  of  alternative  or  reusable  modular 
system  elements. 

c.  The  Offeror  shall  describe  how  its  system  will  allow  for; 
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i.  Quickly  interconnecting,  reconfiguring,  and  assembling  existing 
systems,  subsystems,  and  components; 

ii.  Interchanging  and  using  information,  services  and/or  physical 
items  among  components  within  a  system; 

iii.  Interchanging  and  using  information,  services  and/or  physical 
items  among  systems  within  an  integrated  architecture,  platform, 
PEO,  Community  of  Interest,  or  a  DoD  component; 

iv.  Supporting  reuse  of  software  and  the  common  use  of  components 
across  various  product  lines; 

v.  Transferring  a  system,  component,  or  data,  from  one  hardware  or 
software  environment  to  another. 

d.  The  Offeror  shall  describe  the  degree  to  which  the  defined  interfaces  will 
support  an  Information  Assurance  (IA)  strategy  that  implements  IA 
Processes  in  accordance  with  DoD  Instruction  8500.2  (dated  February  6, 
2003). 

e.  The  Offeror  shall  describe  the  degree  to  which  proposed  interfaces  use 
defined  commercial  or  Government  standards  as  called  for  in  Section  C. 

Subfactor  3.  Treatment  of  Proprietary  or  Vendor-Unique  Elements.  The  Offeror 
shall  justify  any  use  of  proprietary,  vendor-unique,  or  closed  components,  including  but 
not  limited  to  COTS,  and  interfaces  in  current  or  future  designs.  This  justification  shall 
include  documentation  of  the  decision  leading  to  the  selection  of  specific  COTS 
products  (e.g.,  with  test  results,  architectural  suitability,  “best  value”  assessments,  etc.). 
The  Offeror  shall  define  its  process  for  identifying  and  justifying  proprietary,  vendor- 
unique  or  closed  interfaces,  code  modules,  hardware,  firmware,  or  software  to  be  used. 

a.  The  Offeror  shall  describe  how  it  will  employ  hardware  and/or  software 
partitioning  or  other  design  techniques  to  isolate  all  proprietary,  vendor- 
unique  portions  of  interfaces,  hardware,  firmware  and  modules  -  at  the 
lowest  subsystem  or  component  level. 

b.  The  proposal  shall  include  documentation  to  support  the  rationale  for  a 
decision  to  integrate  proprietary,  vendor-unique  or  closed  system 
hardware  and/or  software  functions  within  the  proposed  system. 

c.  The  Offeror  shall  describe  how  the  integration  of  closed  or  proprietary, 
vendor-unique  equipment,  interfaces,  data  systems  or  functions  due  to  a 
unique  or  specific  system  requirement  will  not  preclude  or  hinder  other 
component  or  module  developers  from  interfacing  with  or  otherwise 
developing,  replacing,  or  upgrading  open  parts  of  the  system. 

d.  The  Offeror  shall  identify  and  take  steps  to  prevent  the  open  elements  of 
the  system  from  intertwining  with  proprietary  or  vendor-unique  elements 
in  a  manner  that  restricts  or  limits  the  ability  to  replace  or  upgrade  the 
open  elements  using  an  open  competitive  selection  process. 

e.  The  Offeror  shall  describe  and  demonstrate  that  the  modularity  of  the 
system  design  promotes  identification  of  multiple  sources  of  supply 
and/or  repair,  and  supports  flexible  business  strategies  that  enhance  sub¬ 
contractor  competition. 
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i.  The  Offeror  shall  conduct  a  market  survey  to  identify  candidate  COTS 
and  other  reusable  NDI,  including  Government-owned  assets,  capable  of 
achieving  the  performance  requirements  of  solutions  that  it  has  proposed 
to  custom  build.  [Sound  “ market  research  ”  will  help  identify 
opportunities  to  use  COTS  or  re-use  existing  components  and  is  called  for 
by  the  OSJTF.]  COTS  and  other  NDI  selection  criteria  shall,  at  a 
minimum,  address  the  following  factors;  Electrostatic  Sensitive  Device 
(ESD)  immunity;  Electromagnetic  Interference/Electromagnetic 
Compatibility  (EMI/EMC);  integrated  logistics  support  requirements; 
safety;  reliability  (to  include  the  hardware’s  designed-in  ability  to 
accommodate  such  stresses  as  electrical  power  fluctuation  (voltage, 
current,  frequency)),  temperature,  shock,  vibration,  operating  time 
(duration),  changes  in  atmospheric  pressure,  and  humidity  consistent  with 
the  environment  described  in  the  System  Specification;  maintainability; 
subsystem  perfonnance  trade-offs;  power,  cooling,  and  physical  fonn 
factors;  open  system  architecture  break  out  compatibility;  cost; 
manufacturer’s  quality  assurance  provisions;  market  acceptability; 
obsolescence;  adequacy  of  available  technical  and  computer  software  data 
rights  and  reprocurement  intellectual  property  rights  in  the  product;  and 
merits  of  the  software  supported  by  the  product.  The  Offeror  shall  provide 
documentation  of  the  decision  leading  to  the  selection  of  specific  COTS 
products  ( e.g .,  test  results,  architectural  suitability,  “best  value” 
assessments,  etc.). 

ii.  The  Offeror  shall  identify  those  pre-existing  items  (Government 
intellectual  property  assets,  NDI,  open  source  software,  and  COTS)  it 
intends  to  evaluate  for  reuse.  At  a  minimum,  the  Offeror  shall  describe 

what  artifacts  from  the _ it  intends  to  use  within  its  proposed 

solution.  Exceptions  regarding  reuse  of  pre-existing  items  must  be 
accompanied  by  justification,  such  as  cost  (both  of  adoption  and  life  cycle 
support),  schedule,  functional  and  non-functional  perfonnance,  etc. 

f.  The  Offeror  shall  address  how  it  will  provide  information  needed  to 
support  third-party  development  and  delivery  of  competitive  alternatives 
or  designs  for  software  or  other  components  or  modules  on  an  ongoing 
basis.  This  information  may  be  used  as  part  of  peer  review  processes,  to 
support  Integrated  Product  Teams  (IPTs),  and  to  facilitate  competition  for 
component  suppliers.  The  Offeror  will  provide  a  list  of  those  proprietary 
or  vendor-unique  elements  that  it  requests  be  exempt  from  this  review. 

Subfactor  4.  Life  Cycle  Management  and  Open  Systems.  The  Offeror  shall  describe 
and  demonstrate  the  strategy  for  reducing  product  or  system  and  associated  supportability 
costs  through  insertion  of  COTS  or  reusable  NDI  products. 

a.  The  Offeror  shall  identify  and  demonstrate  a  strategy  to  insert  COTS 
technologies  and  other  reusable  NDI  into  the  system  and  demonstrate  that 
COTS,  other  reusable  NDE  and  other  components  are  logistically 
supported  throughout  the  system’s  life  cycle. 
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i.  The  proposal  shall  identify  specific  hardware  and  software  elements  of 
the  subsystem  designs  that  are  planned  for  COTS,  open  source  software, 
proprietary  and  other  reusable  NDI  replacement  and  the  supportability 
plans  for  those  elements. 

ii.  The  Offeror  shall  demonstrate  how  the  subsystem  is  designed  to  allow 
for  timely  and  cost-effective  replacement  of  subsystem  elements  or 
modules.  The  COTS  selection  processes  shall  be  specifically  addressed, 
including  validation  of  those  processes,  and  shall  be  supported  by 
documentation  of  the  decision  leading  to  the  selection  of  specific  COTS 
products  ( e.g .,  with  test  results,  architectural  suitability,  “best  value” 
assessments,  etc.). 

b.  The  Offeror  shall  provide  a  description  of  processes  that  will  be 
established  and  demonstrate  that  COTS  and  other  reusable  NDI  products 
are  logistically  supported. 

c.  The  Offeror  shall  describe  the  availability  of  commercial  repair  parts  and 
repair  services,  facilities  and  manpower  required  for  life  cycle  support  and 
demonstrate  that  they  are  adequate  to  ensure  long-tenn  support  for  COTS 
and  other  reusable  NDI  products.  The  Offeror  shall  provide  the  proposed 
methodology  for  pass  through  of  COTS  warranties  to  the  Government. 

Factor  (  ):  System  Compliance  with  Naval  OA  Guidance 

The  language  used  in  this  section  will  be  specified  by  the  Community  of  Interest  or  PEO. 
For  example,  PEO  C4I  may  use  language  from  Netcentric  Enterprise  Solutions  for 
Interoperability  (NESI).  The  material  that  follows  should  be  tailored  by  each 
PEO/Community  of  Interest  to  meet  its  specific  technical  requirements,  when  enterprise¬ 
wide  Naval  requirements  do  not  exist.  The  language  should  also  be  tailored  to  address 
different  types  of  contracts,  levels  of  systems  acquisition,  and  phases  in  the  acquisition 
life  cycle. 

Each  Offeror  shall  provide  a  narrative  to  the  Government  entitled  “Naval  Open 
Architecture  Technical  Guidance  Narrative”  (hereinafter  referenced  to  as  the 
“Narrative”).  In  preparation  for  drafting  the  Narrative,  Offerors  are  requested  to 
thoroughly  review  the  [PEO-specified]  technical  guidance  points  provided  in  Table  A 
below.  The  technical  guidance  points  represent  the  critical  technical  characteristics 
required  to  implement  the  NOA  design  for  deliverables  under  the  contract  awarded 
pursuant  to  this  RFP. 

1 .  Each  Offeror  shall  provide  a  Narrative  explaining  how  each  technical 
guidance  point  in  Table  A  is  addressed  in  the  proposal.  For  those 
technical  guidance  points  in  Table  A  that  the  Offeror  asserts  are  not 
applicable  or  not  relevant  to  deliverables  under  the  contract,  the  Offeror 
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shall,  in  the  Narrative,  explain  its  basis  for  asserting  non-applicability  or 
non-relevance. 

2.  The  NOA  Compliance  subfactor  is  directed  to  each  of  the  technical 
guidance  points  in  Table  A  below,  and  the  Offeror’s  ability  to  provide  a 
Narrative  explaining  how  its  proposal  meets  each  technical  guidance  point 
as  defined  by  the  [insert  relevant  reference ]. 


Table  A 


[PEO-specified\  Technical 
Guidance  Points 

[ PEO -specified]  Reference  Document  Citation 

Component  design 

Portability 

Location  transparency 

Client  server 

Data  distribution 

State  data  coherency 

Computational  flow 

Fault  tolerance 

Scalability 

Real-time  performance 

Process,  thread  &  memory 
management 

Data  brokers 

Cabling  and  Cabinets 

Information  Transfer 

Computing  Resources 

Peripherals 

Operating  Systems 

Adaptation  Middleware 

Distribution  Middleware 

Frameworks 

Dynamic  Resource  Management 

Instrumentation 

Failure  Management 

Information  Assurance 

Time  Service 

Programming  Language  Facilities 

Displays 

System  Test  and  Certification 

Selection  of  Standards 
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Factor  (  ):  Management  Approach 

The  first  paragraph  below  is  standard  contract  language  with  some  modification  to  reflect 
the  objective  of  facilitating  competition  at  appropriate  system  or  sub-system  levels. 

While  the  number  of  contractors  or  subcontractors  working  on  a  contract  is  not 
necessarily  a  guaranty  of  openness,  effective  competition  at  the  component-level  is 
facilitated  by  NOA.  The  second  paragraph  articulates  the  view  that  true  competition 
cannot  be  measured  by  the  percentage  of  work  awarded  but  rather  the  significance  of 
their  contributions. 

The  Offeror  shall  describe  its  approach  to  managing  the  efforts  required  for  this  contract. 
Of  particular  interest  to  the  Government  is  the  Offeror’s  approach  for  facilitating 
competition  at  various  levels  (tiers)  of  the  logical  or  modular  subdivisions  or  tasks  and 
for  awarding  significant  portions  of  the  overall  system  to  third-party  sources. 

The  Offeror  shall  describe  its  approach  for  using  Integrated  Product  Teams  (IPTs)  to 
improve  processes,  proactively  manage  risk  and  increase  efficiency.  The  Offeror  shall 
describe  steps  it  shall  take  to  educate  IPT  members  and  others  involved  in  the  project  on 
the  importance  and  principles  of  NOA. 


Factor  (  )  Data  Rights  and  Patent  Rights 


The  Offeror  shall  propose  the  extent  to  which  the  rights  in  technical  data  (TD),  computer 
software  (CS),  computer  software  documentation  (CSD),  and  inventions/patents  offered 
to  the  Government  ensure  unimpeded,  innovative,  and  cost  effective  production, 
operation,  maintenance,  and  upgrade  of  the  [SYSTEM NAME\  throughout  its  life  cycle; 
allow  for  open  and  competitive  procurement  of  [SYSTEM  NAME]  enhancements;  and 
permit  the  transfer  of  the  [SYSTEM  NAME\  non-proprietary  object  code  and  source  code 
to  other  contractors  for  use  on  other  systems  or  platforms. 

The  Offeror  shall  describe  its  plan  for  making  design  and  interface  information  available 
as  soon  as  possible  after  it  is  defined  or  established.  The  Offeror  shall  establish  and 
maintain  a  process  that  will  provide  “early  and  often”  design  disclosure  directly  to  the 
Government  or  to  third-party  contractors  via  Government-established  access  (e.g.,  the 
Naval  Sea  Systems  Command  Software/Hardware  Asset  Reuse  Enterprise  (SHARE) 
library  or  other  Navy  and  Marine  Corps  repository/library  resources)  to  in-process  design 
documentation  and  computer  software.  Access  to  this  infonnation  shall  be  supported 
using  industry  standards  and  at  minimal  cost  to  the  Government.  The  exchange  of 
information  shall  be  structured  so  as  to  protect  the  Offeror’s  and  third-party  developers’ 
proprietary  in  the  information.  The  Offeror  shall  address  how  it  intends  to  resolve  any 
comments  from  the  Government  and  third-party  contractors.  The  Offeror  shall  describe 
how  it  intends  to  provide  all  non-proprietary  licenses,  source  code,  drawings,  repair  and 
engineering  documentation  to  the  Government  and  third-party  contractors  at  specified 
key  events  or  at  defined  intervals. 
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The  Data  Rights  and  Patent  Rights  offered  shall  be  provided  as  attachments  to  the 
proposal.  The  Offeror  shall  cite  specific  examples  of  the  Government's  IPR  that  illustrate 
the  tenets  of  the  offer,  including  an  overview  of  the  information  provided  in  the  following 
required  attachments,  as  well  as  a  discussion  of  how  the  information  contained  in  the 
attachments  impacts  or  illustrates  the  tenets  of  the  proposal; 

2.  The  Offeror  shall  provide  the  following  infonnation  as  attachments  to  its  offer; 

a.  Rights  in  Noncommercial  TD,  Noncommercial  CS,  and 
Noncommercial  CSD. 

i.  The  7017  List.  The  Offeror  shall  attach  to  its  offer  a  list 
identifying  all  noncommercial  TD,  CS,  and  CSD  that  it  asserts 
should  be  delivered  with  other  than  unlimited  rights.  Specific 
instructions  and  requirements  concerning  this  list  are  set  forth  in 
the  DFARS  252.227-7017  “Identification  and  Assertion  of  Use, 
Release,  or  Disclosure  Restrictions”  (June  1995)  provision 
incorporated  at  Section  K  of  this  solicitation.  If  the  Offeror  is 
awarded  a  contract,  the  7017  List  shall  be  attached  to  the  contract. 

ii.  The  7028  List.  The  Offeror  shall  attach  to  its  offer  a  list 
identifying  all  noncommercial  TD,  CS,  and  CSD  that  it  intends  to 
deliver  with  other  than  unlimited  rights  and  that  are  identical  or 
substantially  similar  to  TD,  CS,  or  CSD  that  the  Offeror  has 
delivered  to,  or  is  obligated  to  deliver  to,  the  Government  under 
any  contract  or  subcontract.  Specific  instructions  and  requirements 
concerning  this  list  are  set  forth  in  the  DFARS  252.227-7028 
“Technical  Data  or  Computer  Software  Previously  Delivered  to  the 
Government”  (June  1995)  provision  incorporated  at  Section  K  of 
this  solicitation.  Additionally,  if  there  is  no  data  or  software  to  be 
identified  in  the  7028  list,  the  Offeror  shall  submit  the  list  and 
enter  “None”  as  the  body  of  the  list.  If  the  Offeror  is  awarded  a 
contract,  the  7028  List  shall  be  attached  to  the  contract. 

iii.  Supplemental  Information.  The  Offeror  shall  attach  to  its  offer  a 
statement,  entitled  “Supplemental  Information — Noncommercial 
Technical  Data,  Noncommercial  Computer  Software, 
Noncommercial  Computer  Software  Documentation”  (the 
statement)  that,  for  each  item  of  noncommercial  TD,  CS,  or  CSD 
that  the  Offeror  asserts  should  be  delivered  with  specifically 
negotiated  license  rights  or  other  non-standard  rights  (as  discussed 
at  DFARS  252.227-7013  “Rights  in  Technical  Data  - 
Noncommercial  Items”  (Nov  1995)  and/or  DFARS  252.227-7014 
“Rights  in  Noncommercial  Computer  Software  and 
Noncommercial  Computer  Software  Documentation”  (June  1995)), 
sets  forth  a  complete  description  of  all  such  proposed  non-standard 
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restrictions  on  the  Government’s  ability  to  use,  modify,  release, 
perform,  display,  or  disclose  such  TD,  CS,  or  CSD.  This 
information  may  be  provided  by  referencing  any  proposed  non¬ 
standard  license  agreement  that  is  attached  to  the  statement.  The 
Offeror  shall  submit  the  statement  as  an  attachment  to  its  offer, 
dated  and  signed  by  an  official  authorized  to  contractually  obligate 
the  Offeror.  If  there  is  no  information  to  be  included  in  the 
statement,  the  Offeror  need  not  submit  the  statement.  If  the 
Offeror  is  awarded  a  contract,  any  statement  provided  will  be 
attached  to  the  contract. 

b.  Rights  in  Commercial  TD,  Commercial  CS,  and  Commercial  CSD. 

i.  The  Offeror  shall  attach  to  its  offer  a  list,  entitled  “Commercial 
Technical  Data,  Commercial  Computer  Software,  and  Commercial 
Computer  Software  Documentation-Government  Use  Restrictions” 
(the  Commercial  Restrictions  List),  that  provides  the  following 
information  regarding  all  commercial  TD,  CS,  and  CSD  that  the 
Offeror  (including  its  sub-Offerors  or  suppliers,  or  potential  sub- 
Offerors  or  suppliers,  at  any  tier)  intends  to  deliver  with  other  than 
unlimited  rights;  (1)  identification  of  the  data  or  software;  (2) 
basis  for  asserting  restrictions,  such  as  licensed  products  including 
open  source;  (3)  asserted  rights  category  (e.g.  GPR  or  restricted 
rights);  and  (4)  name  of  the  entity  asserting  restrictions.  For  any 
item  designated  as  NDI,  the  Offeror  is  requested  to  provide  details 
of  the  Agency  and  level  therein  that  paid  for  development  and  the 
contract  number(s)  and  dates  wherein  payments  were  received. 

For  each  entry  in  the  list  citing  an  asserted  rights  category  other 
than  the  standard  license  rights  applicable  to  commercial  TD  as  set 
forth  in  the  DFARS  252.227-7015  “Technical  Data  -  Commercial 
Items”  (Nov  1995)  clause,  the  Offeror  shall  provide  a  complete 
description  of  the  asserted  rights  (e.g.,  a  specially  negotiated 
license,  open  source,  or  the  license  customarily  offered  to  the 
public);  this  information  may  be  provided  by  referencing  any 
proposed  non-standard  or  commercial  license  agreement  that  is 
attached  to  the  list,  but  in  all  cases,  the  non-standard  or  commercial 
license  will  be  attached  for  Government  review.  The  Offeror  shall 
submit  the  Commercial  Restrictions  List  as  an  attachment  to  its 
offer,  dated  and  signed  by  an  official  authorized  to  contractually 
obligate  the  Offeror.  If  there  is  no  information  to  be  included  in 
the  Commercial  Restrictions  List,  the  Offeror  shall  submit  the  list 
and  enter  “None”  as  the  body  of  the  list.  If  the  Offeror  is  awarded 
a  contract,  the  Commercial  Restrictions  List  shall  be  attached  to 
the  contract. 


39 


Distribution  Statement  A  -  Approved  for  Public  Release; 
Distribution  is  unlimited. 


NOA  Contract  Guidebook  v.2.0 
June  30,  2010 

ii.  The  Offeror  shall  attach  to  its  offer  a  list,  entitled  “Commercial- 
Off-the-Shelf  (COTS)  Licenses  -  Identification  and  Licensing” 

(the  COTS  List),  providing  information  concerning  all  COTS 
licenses  for  which  it  intends  to  pay  license  fees  and  the  amount  of 
the  fees  in  order  to  perfonn  under  the  contract.  The  Offeror  shall 
submit  the  COTS  List  as  an  attachment  to  its  offer,  dated  and 
signed  by  an  official  authorized  to  contractually  obligate  the 
Offeror.  The  Offeror’s  COTS  list  shall  also  include  a  statement 
explaining  how  the  COTS  will  be  used  in  the  system.  If  there  is  no 
information  to  be  included  in  the  COTS  List,  the  Offeror  shall 
submit  the  list  and  enter  “None”  as  the  body  of  the  list.  If  the 
Offeror  is  awarded  a  contract,  the  COTS  List  shall  be  attached  to 
the  contract. 

c.  Rights  in  Background  Inventions. 

i.  The  Offeror  shall  attach  to  its  offer  a  list,  entitled  “Background 
Inventions — Identification  and  Licensing”  (the  BIIL  List), 
providing  information  concerning  all  background  inventions.  A 
“background  invention”  is  any  invention,  other  than  a  subject 
invention,  that  is  covered  by  any  patent  or  pending  patent 
application  in  which  the  Offeror  (including  its  sub-Offerors  or 
suppliers,  or  potential  sub-Offerors  or  suppliers,  at  any  tier)  (1)  has 
any  right,  title,  or  interest;  and  (2)  proposes  to  incorporate  into  any 
items,  components,  or  processes  (ICP)  to  be  developed  or 
delivered,  or  that  will  be  described  or  disclosed  in  any  TD,  CS,  or 
CSD  to  be  developed  or  delivered,  under  the  resulting  contract. 

For  each  background  invention,  the  BIIL  List  shall  identify  (1)  the 
invention,  by  serial  number,  title,  and  date  of  the  patent  application 
or  issued  patent;  (2)  the  ICP,  TD,  CS,  and  CSD  that  will 
incorporate  or  disclose  the  invention;  (3)  the  nature  of  the  Offeror's 
right,  title,  or  interest  in  the  invention;  and  (4)  whether  the  Offeror 
is  willing  to  sell  to  the  Government  a  license  to  practice  the 
invention,  and  if  so,  a  complete  description  of  the  terms  of  such 
proposed  license.  The  Offeror  shall  submit  the  BIIL  List  as  an 
attachment  to  its  offer,  dated  and  signed  by  an  official  authorized 
to  contractually  obligate  the  Offeror.  If  there  is  no  information  to 
be  included  in  the  BIIL  List,  the  Offeror  shall  submit  the  list  and 
enter  “None”  as  the  body  of  the  list.  If  the  Offeror  is  awarded  a 
contract,  the  BIIL  List  shall  be  attached  to  the  contract. 

ii.  The  Offeror  shall  attach  to  its  offer  a  list,  entitled  “Third  Party 
Patent  Rights  -  Identification  and  Licensing”  (the  3PRIL  List), 
providing  information  concerning  all  third  party  patent  rights  for 
which  it  intends  to  pay  royalties  and  the  amount  of  the  royalties  in 
order  to  perform  under  the  contract.  The  Offeror  shall  submit  the 
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3PRIL  List  as  an  attachment  to  its  offer,  dated  and  signed  by  an 
official  authorized  to  contractually  obligate  the  Offeror.  If  there  is 
no  infonnation  to  be  included  in  the  3PRIL  List,  the  Offeror  shall 
submit  the  list  and  enter  “None”  as  the  body  of  the  list.  If  the 
Offeror  is  awarded  a  contract,  the  3PRIL  List  shall  be  attached  to 
the  contract. 

Evaluation  Subfactor  (  ):  OA  Past  Performance 

The  Offeror  shall  demonstrate,  through  its  use  of  previously  developed  similar 
technologies,  the  Offeror’s  ability  to  meet  the  design,  development,  testing,  and 
production  requirements  of  this  solicitation,  in  particular  its  approach  to  a  modular  open 
system  design,  in  the  quantities  and  schedules  specified.  The  Offeror  shall  provide  a  list 
of  all  relevant  contracts  and  subcontracts  of  similar  work  scope  or  technical  complexity 
to  the  efforts  described  herein  within  the  last  five  (5)  years.  In  addition  to  contracts  and 
subcontracts  performed  by  the  Offeror,  relevant  contracts  and  subcontracts  of  an  acquired 
company,  division,  or  subsidiary  shall  be  identified.  The  Offeror  shall  place  particular 
emphasis  on  DoD  or  Government  contracts  and  subcontracts,  especially  those  that 
involved  a  modular  open  systems  approach. 

If  the  Offeror  did  not  perform  similar  projects  during  the  last  five  years,  the  Offeror  may 
discuss  other  related  projects  that  demonstrate  the  Offeror’s  capabilities  to  perform  work 
of  similar  nature  and  magnitude.  Note,  if  the  Offeror  omits  projects  or  contracts  of  which 
the  Government  evaluation  team  is  aware  or  becomes  aware,  then  customer  assessments 
may  be  sought  from  the  relevant  program  and  technical  support  offices.  Offerors  are 
advised  that  (1)  the  Government  may  contact  any  or  all  references  listed  in  the  proposal 
and  other  third  parties,  unreferenced  customers,  agencies,  Offerors,  consumer  protection 
organizations,  etc.,  for  performance  information,  or  use  any  other  data  available  (such  as 
contractor  Performance  Assessment  Reporting  System  (CPARS));  (2)  the  Government 
reserves  the  right  to  use  any  such  information  received  as  part  of  its  evaluation  of  the 
Offeror’s  past  perfonnance;  and  (3)  if  the  Offeror  omits  projects  of  which  the 
Government  evaluation  team  is  aware  or  becomes  aware,  customer  assessments  may  be 
sought  from  the  relevant  organizations. 

For  each  listed  contract,  the  Offeror  shall  prepare  a  synopsis  that  includes  a  narrative  self- 
assessment  of  the  contract  and  specific  details  describing  why  the  contract  was,  or  was 
not,  successful.  Each  synopsis  shall  be  in  the  following  format; 

( 1 )  Contract  number; 

(2)  Customer’s  name,  address,  telephone  number,  and  a  point  of  contact 
(whether  Government  or  Commercial),  and  whether  the  Offeror  was  the 
prime  Offeror  or  a  sub-Offeror; 

(3)  Contract  type; 

(4)  Cost  information; 

(5)  Brief  product  description,  including  quantities,  hours,  and  state  of 
acquisition  (i.e.,  development  or  production); 
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(6)  Self-Assessment.  The  Offeror  shall  provide  a  self  assessment  of  its 
performance  under  each  contract  identified  above.  The  self  assessment 
shall  address  (a)  the  degree  to  which  the  Offeror  demonstrated  its  design 
approach,  plans  for  technology  insertion,  and  sustainment  strategy  were 
consistent  with  the  modular  open  systems  requirements,  (b)  the  degree  to 
which  the  Offeror  managed  the  impact  of  changing  requirements  and 
evolving  technology  on  the  system’s  ability  to  continue  to  satisfy 
improved  capabilities  over  time,  (c)  the  degree  to  which  the  Offeror’s  test 
and  evaluation  planning  contained  the  means  for  testing  the  conformance 
to  open  standards  to  ensure  the  openness  of  key  interfaces  throughout  the 
system  life  cycle,  and  (d)  the  degree  to  which  the  Offeror’s  approach 
contains  capabilities  to  easily  and  quickly  update,  revise,  and  change  the 
system  as  threats  (warfighting  and  infonnation  assurance  threats)  or 
technologies  (COTS  or  reusable)  evolve.  Cost  growth,  material  problems, 
manufacturing  problems,  quality  problems,  labor  problems,  facility 
problems,  and  delivery  delays  shall  be  disclosed  and  fully  explained.  The 
Offeror  shall  demonstrate  how  it  was  able  to  resolve  (or  why  it  could  not 
resolve)  special  or  unexplained  problems  as  well  as  difficulties  in  meeting 
delivery  schedule,  perfonnance,  or  cost  parameters.  Emphasis  shall  be 
placed  on  the  Offeror’s  ability  to  solve  problems  associated  with  critical 
testing,  quality  control,  and  production.  Furthermore,  the  Offeror  shall 
indicate  any  quality  awards  or  recognition  received. 

(7)  Customer  References.  The  Offeror  shall  request  Customer  questionnaires 
to  be  submitted  directly  to  the  Procurement  Contracting  Officer’s  (PCO’s) 
representative  and/or  copies  submitted  with  the  Offeror’s  proposal  and 
provide  the  following  information  for  each  described  contract: 

•  The  Procuring  Contracting  Officer’s  name,  address,  and  telephone 
number. 

•  The  Administrative  Contracting  Officer’s  name,  address,  and 
telephone  number. 

•  The  Government  and  Offeror’s  Program  Managers’  names,  addresses, 
and  telephone  numbers. 

•  The  names,  addresses,  and  telephone  numbers  of  other  individuals 
having  knowledge  of  the  Offeror’s  performance  under  each  contract. 

At  a  minimum,  the  Government’s  questionnaire  for  assessing  an  Offeror’s  OA  past 
performance  must  address: 

•  The  degree  to  which  the  Offeror  demonstrated  its  design  approach,  plans 
for  technology  insertion,  and  sustainment  strategy  were  consistent  with  the 
modular  open  systems  requirements. 

•  The  degree  to  which  the  Offeror  managed  the  impact  of  changing 
requirements  and  evolving  technology  on  the  system’s  ability  to  continue 
to  satisfy  improved  capabilities  over  time. 

•  The  degree  to  which  the  Offeror’s  test  and  evaluation  planning  contained 
the  means  for  testing  the  conformance  to  open  standards  to  ensure  the 
openness  of  key  interfaces  throughout  the  system  life  cycle. 
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•  The  degree  to  which  the  Offeror’s  approach  contains  capabilities  to  easily 
and  quickly  update,  revise,  and  change  the  system  as  threats  (warfighting 
and  information  assurance  threats)  or  technologies  (COTS  or  reusable) 
evolve. 


COST  PROPOSAL  (NOA  RELATED) 

Section  (  )  Supplemental  Information  Concerning  Cost/Price  of  Noncommercial 
Technical  Data  (TD),  Noncommercial  Computer  Software  (CS),  and 
Noncommercial  Computer  Software  Documentation  (CSD) 

(a)  Cost/Price  Information.  In  addition  to  the  submission  requirement  of  DFARS 
252.227-7017,  the  Offeror  shall  provide  a  list  entitled  “Supplemental  Infonnation 
Concerning  Cost/Price  of  Noncommercial  Technical  Data  (TD),  Noncommercial 
Computer  Software  (CS),  and  Noncommercial  Computer  Software  Documentation 
(CSD)”  (hereinafter  the  Supplemental  7017  Cost/Price  List).  This  list  shall  be  provided 
as  an  attachment  to  proposal.  This  list  shall  provide  supplemental  information 
concerning  the  noncommercial  TD,  CS,  or  CSD  identified  in  the  DFARS  252.227-7017 
“Identification  and  Assertion  of  Use,  Release,  or  Disclosure  Restriction”  list  (hereinafter 
7017  List),  as  follows: 

(1)  License  Option  Price  Information.  For  each  item  of  noncommercial  TD,  CS, 
and/or  CSD  that  the  Offeror  asserts  should  be  delivered  with  less  than  Government 
Purpose  Rights  (GPR)  (as  defined  in  (DFARS  252.227-7013  “Rights  in  Technical  Data  - 
Noncommercial  Items”  (Nov  1995)  and/or  DFARS  252.227-7014  “Rights  in 
Noncommercial  Computer  Software  and  Noncommercial  Computer  Software 
Documentation”  (June  1995)),  and  for  which  the  Offeror  is  willing  to  sell  to  the 
Government  greater  rights  than  those  identified  in  the  7017  List,  the  Offeror  shall  identify 
those  greater  rights,  provide  an  option  price  at  which  the  Government  may  purchase  such 
greater  rights,  and  identify  the  period  of  time  during  which  the  option  is  available  for  the 
Government  to  exercise. 

(2)  Govermnent  Preferences.  The  Offeror  may  state  any  license  option  price  as  a 
firm  fixed  price,  a  percentage  royalty  rate  (or  use  fee),  or  any  other  comparable 
compensation  scheme,  provided  that  the  Government  can  reasonably  calculate  a  sum- 
certain  price  for  the  license  option  using  the  price  information  and  terms  and  conditions 
information  the  Offeror  provided.  The  Government  prefers  that  any  license  option  prices 
the  Offeror  provides  in  the  Supplemental  7017  Cost/Price  List  cover  all  noncommercial 
CS,  noncommercial  CSD,  and  noncommercial  TD  included  in  any  affected  software  and 
that  the  Offeror  state  them  on  a  price-per-system  basis. 

(b)  Duty  to  Submit  Negative  List.  If  there  is  no  supplemental  infonnation  to  be 
submitted  in  the  Supplemental  7017  Cost/Price  List  the  Offeror  shall  submit  the  list  and 
enter  “None”  as  the  body  of  the  list.  Failure  to  provide  a  list  may  render  the  Offeror 
ineligible  for  award. 
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(c)  Use  During  Source  Selection.  Information  provided  in  the  Supplemental  7017 
Cost/Price  List,  as  well  as  the  information  provided  in  the  7017  List,  may  be  used  in  the 
source  selection  process  as  part  of  the  Government’s  best  value  analysis  to  evaluate  the 
impact  on  the  Government’s  ability  to  use,  re-use,  or  disclose  the  TD,  CS,  and/or  CSD 
for  government  purposes. 

Section  (  )  Supplemental  Information  Concerning  Cost/Price  of  Commercial 
Computer  Software  ICS),  and  Commercial  Computer  Software  Documentation 
(CSD)  and  Commercial  Technical  Data  (TD) 

(a)  Cost/Price  Information.  The  Offeror  shall  provide  a  list  to  the  Government,  entitled 
“Commercial  Restrictions  List  -  Cost/Price  Information”  (hereinafter  the  CRLCPI  List). 
This  list  shall  be  provided  as  an  attachment  to  proposal.  The  CRLCPI  List  shall  state  a 
license  option  price  for  all  commercial  CS,  commercial  CSD,  and  commercial  TD  on  the 
CRL  List  for  which  the  Offeror  is  willing  to  sell  the  Govermnent  a  license.  If  the  Offeror 
is  willing  to  provide  a  license  option,  the  Offeror  shall  identify  the  specific  rights  it  is 
willing  to  grant,  and  the  period  of  time  during  which  the  option  is  available  for  the 
Government  to  exercise. 

(b)  License  Option  Pricing:  Government  Preferences.  The  Offeror  may  state  any 
license  option  price  as  a  firm  fixed  price,  a  percentage  royalty  rate  (or  use  rate),  or  any 
other  comparable  compensation  scheme,  provided  that  the  Government  can  reasonably 
calculate  a  sum-certain  price  for  the  license  option  using  the  price  infonnation  the 
Offeror  provided.  The  Government  prefers  that  any  license  option  prices  the  Offeror 
provides  in  the  CRLCPI  List  cover  all  commercial  CS,  commercial  CSD,  and  commercial 
TD  included  in  any  affected  software  and  that  the  Offeror  state  them  on  a  price-per- 
system  basis. 

(c)  Duty  to  Submit  Negative  List.  If  the  Offeror  has  no  Option  License  Pricing  to 
provide  in  the  CRLCPI  List,  the  Offeror  shall  still  submit  the  CRLCPI  List  and  enter 
“None”  in  the  body  of  the  List.  Failure  to  provide  a  list  may  render  the  Offeror  ineligible 
for  award. 

Section  (  )  Supplemental  Information  Concerning  Cost/Price  of  Background 
Inventions 


(a)  License  Option  Pricing:  Government  Preferences.  The  Offeror  may  state  any 
license  option  price  as  a  firm  fixed  price,  a  percentage  royalty  rate  (or  use  rate),  or  any 
other  comparable  compensation  scheme,  provided  the  Government  can  reasonably 
calculate  a  sum-certain  price  for  the  license  using  the  price  infonnation  provided  by  the 
Offeror.  The  Government  prefers  that  any  license  option  prices  stated  by  the  Offeror  in 
the  Background  Inventions  List  -  Cost/Price  Infonnation  (BICPI  List)  cover  all 
background  inventions  included  in  any  affected  software,  and  the  Offeror  states  them  on 
a  price-per-system  basis. 
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(b)  Duty  to  Submit  Negative  List.  If  the  Offeror  has  no  Option  License  Pricing  to 
provide  in  the  BICPI  List,  the  Offeror  shall  still  submit  the  BICPI  List  and  enter  “None” 
in  the  body  of  the  list.  Failure  to  provide  a  list  may  render  the  Offeror  ineligible  for 
award. 


Software  Process  Improvement  Initiative  Guidance14 

The  Navy  and  Marine  Corps  shall  request  that  Offerors  submit  a  draft  version  of  their 
Software  Development  Plan  (SDP)  as  a  part  of  their  proposal  package  as  well  as  a 
rationale  for  how  the  Navy  justify  their  process  selection. 

“As  a  part  of  the  proposal,  Offerors  shall  submit  a  draft  version  of  their  SDP  in 
accordance  with  the  content  defined  in  the  SOW.  The  SDP  may  be  formatted  as 
desired  by  the  Offeror  but  must  contain  the  information  described  by  the  SDP  DID. 
The  SDP  is  not  page  limited.  An  SDP,  if  it  is  to-the -point  and  appropriate,  may  be 
preferable  to  a  SDP  that  is  excessively  wordy  and  contains  non-essential  material. 

“Offerors  shall  also  submit,  as  a  part  of  their  proposal,  an  SDP  Rationale  which 
describes  why  their  specific  approach  is  appropriate  for  the  system  to  be  procured  and 
how  their  proposed  processes  are  equivalent  to  those  articulated  by  CMMI® 
capability  level  3. 

“Offerors  shall  submit  a  description  of  previous  experience  in  developing  software  of 
the  same  nature  as  this  solicitation.  As  a  part  of  this  description,  the  Offerors  shall 
describe  the  extent  to  which  personnel  who  contributed  to  these  previous  efforts  will 
be  supporting  this  solicitation. 

“Offerors  shall  submit  a  description  of  previous  experience  in  developing  software 
using  the  same  or  similar  processes  and  approaches  as  proposed  for  this  solicitation. 
Offerors  shall  describe  the  extent  to  which  personnel  who  contributed  to  these 
previous  efforts  will  be  supporting  this  solicitation.  Offerors  shall  also  describe  any 
previous  CMMI  or  equivalent  model-based  process  maturity  appraisals  performed. 

As  a  part  of  this  description,  Offerors  shall  identify  the  organizational  entity  and 
location  where  the  appraisal  was  performed,  the  type  of  evaluation,  the  organization 
performing  the  evaluation,  and  the  level  earned.” 


14  Assistant  Secretary  of  the  Navy  (Research,  Development  and  Acquisition)’ s 
Memorandum  on  “Software  Process  Improvement  Initiative  Contract  Language,”  dated 
November  17,  2006. 
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Chapter  D:  RECOMMENDATIONS  FOR  SECTION  M 
(EVALUATION  CRITERIA)  LANGUAGE 


Although  the  Guidebook  was  developed  for  mixed  systems  comprised  of  hardware, 
middleware  and  software  elements,  the  recommended  language  can  be  easily  tailored  to 
reflect  hardware-  or  software-only  acquisitions. 

EVALUATION  FACTORS 

The  Government  will  evaluate  the  Offeror’s  proposal  in  accordance  with  the  factors  and 
subfactors  set  forth  below; 


Naval  Open  Architecture  Guidance 

Factor  ( ):  Technical  Approach  and  Processes 

In  evaluating  the  OA  Technical  Approach  and  Processes,  the  Government  will  use 
information  provided  in  the  proposal  to  assess  the  Offeror’s  ability  to  execute; 


Subfactor  1. 
Subfactor  2. 
Subfactor  3. 
Subfactor  4. 


Open  Systems  Approach  and  Goals 

Interface  Design  and  Management 

Treatment  of  Proprietary  or  Vendor-Unique  Elements 

Life  Cycle  Management  and  Open  Systems 


Factor  (  ):  System  Compliance  with  Naval  OA  Guidance 

In  evaluating  the  System  Compliance  with  Naval  OA  Guidance,  the  Government  will  use 
information  in  the  proposal  to  assess  the  degree  to  which  the  Offeror’s  approach  complies 
with  PEO-specified  (or  Naval  Enterprise)  Technical  Guidance  Points  as  identified  in 
Table  A  of  Section  L. 


Factor  (  ):  Management  Approach 

In  evaluating  the  Management  Approach,  the  Government  will  use  infonnation  in  the 
proposal  to  assess  the  degree  to  which  the  Offeror’s  approach  facilitates  competition  at 
various  levels  (tiers)  of  the  offered  modular  system,  awards  significant  portions  of  the 
overall  system  to  third  party  sources,  and  uses  Integrated  Product  Teams  (IPT)  to 
improve  processes,  manage  risk,  and  increase  efficiency. 

Factor  (  ):  Data  Rights,  Computer  Software  Rights  and  Patent  Rights 

In  evaluating  the  Data  Rights  and  Patent  Rights,  the  Govermnent  will  use  information  in 
the  proposal  to  assess  the  extent  to  which  the  rights  in  technical  data  (TD),  computer 
software  (CS),  computer  software  documentation  (CSD),  and  inventions/patents  offered 
to  the  Government  ensure  unimpeded,  innovative,  and  cost  effective  production, 
operation,  maintenance,  and  upgrade  of  the  [SYSTEM NAME]  throughout  its  life  cycle; 
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allow  for  open  and  competitive  procurement  of  [SYSTEM  NAME]  enhancements;  and 
permit  the  transfer  of  the  [SYSTEM  NAME]  non-proprietary  object  code  and  source  code 
to  other  contractors  for  use  on  other  systems  or  platforms. 

Factor  (  ):  Past  Performance 

Subfactor  1.  Offeror’s  OA  Past  Performance  Submissions 

In  assessing  the  Offeror’s  past  performance  submissions  on  similar  contracts,  the 
Government  will  consider  how  well  the  Offeror  implemented  Open 
Architecture  principles  and  used  a  modular  open  system  approach,  including: 

•  The  degree  to  which  the  Offeror  demonstrated  that  its  design  approach, 
plans  for  technology  insertion,  and  sustainment  strategy  were  consistent 
with  the  modular  open  systems  requirements. 

•  The  degree  to  which  the  Offeror  managed  the  impact  of  changing 
requirements  and  evolving  technology  on  the  system’s  ability  to  continue 
to  satisfy  improved  capabilities  over  time. 

•  The  degree  to  which  the  Offeror’s  test  and  evaluation  planning  contained 
the  means  for  testing  the  conformance  to  open  standards  to  ensure  the 
openness  of  key  interfaces  throughout  the  system  life  cycle. 

•  The  degree  to  which  the  Offeror’s  approach  contains  capabilities  to  easily 
and  quickly  update,  revise,  and  change  the  system  as  threats  (warfighting 
and  information  assurance  threats)  or  technologies  (COTS  or  reusable) 
evolve. 

Factor  ( ):  Cost  Proposal  (NOA  Related) 

The  Government  will  evaluate  the  following  costs  with  respect  to  how  they  further  Naval 
Open  Architecture  goals: 

•  Supplemental  Information  Concerning  Cost/Price  of  Noncommercial  Technical 
Data  (TD),  Noncommercial  Computer  Software  (CS),  and  Noncommercial 
Computer  Software  Documentation  (CSD) 

•  Supplemental  Information  Concerning  Cost/Price  of  Commercial  Computer 
Software  (CS),  and  Commercial  Computer  Software  Documentation  (CSD)  and 
Commercial  Technical  Data  (TD) 

•  Supplemental  Information  Concerning  Cost/Price  of  Background  Inventions 

Software  Process  Improvement  Guidance15 

At  a  minimum,  the  following  three  evaluation  factors  relating  to  the  Offeror's  software 
development  process  shall  be  included  in  Section  M: 


15  Assistant  Secretary  of  the  Navy  (Research,  Development  and  Acquisition) ’s 
Memorandum  on  “Software  Process  Improvement  Initiative  Contract  Language,”  dated 
November  17,  2006. 
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a)  Factor  x  -  Software  development  approach 

Description:  The  Government  will  evaluate  the  Offeror’s  proposed  software 
development  approach  to  ensure  it  is  appropriate  for  the  system  to  be  developed  and 
meets  standard  levels  of  completeness  and  process  quality.  For  this  evaluation,  the 
Government  will  rely  primarily  on  the  draft  SDP  and  the  SDP  Rationale. 

Criteria:  IEEE/EIA  Std.  12207.1,  Section  4.2.3,  H.3  -  Characteristics  of  Life  Cycle  Data 

b)  Factor  x  -  Software  development  experience 

Description:  The  Government  will  evaluate  the  Offeror’s  previous  experience  in 
developing  software  of  the  same  nature  as  that  being  acquired  with  this  solicitation. 

Factor  x  -  Software  development  process  experience 

Description ;  The  Government  will  evaluate  the  Offeror's  previous  experience  in 
developing  software  using  the  same  or  similar  approach  as  proposed  for  this  solicitation. 
The  results  of  any  standard  model-based  process  maturity  appraisals  performed  within  24 
months  prior  to  proposal  submission,  and  the  number  of  proposed  staff  experienced  in 
using  these  processes  will  be  part  of  the  evaluation  criteria. 
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Chapter  E:  RECOMMENDATIONS  FOR  INCENTIVIZING 

CONTRACTORS 


In  response  to  a  December  2005  report  and  recommendations  by  the  Government 
Accountability  Office,  “DEFENSE  ACQUISITIONS:  DoD  Has  Paid  Billions  in  Award 
and  Incentive  Fees  Regardless  of  Acquisition  Outcomes,”  the  Defense  Department  on 
March  29,  2006,  issued  a  Memorandum  on  Award  Fee  Contracts  (FAR  16,  DFARS  215, 
DFARS  216).  We  recommend  that  this  memorandum  be  consulted  when  preparing  an 
Award  Fee  Plan.  (It  is  available  on  the  Office  of  the  Secretary  of  Defenses  website  at 
http://www.acq.osd.mil/dpap/policv/policvvault/2006-0334-DPAP.pdf) 

Subsequently,  the  Government  Accountability  Office  (GAO)  in  May  2009  issued  a 
follow-up  report  on  award  fee  practices,  “Federal  Contracting:  Guidance  on  Award  Fees 
Has  Led  to  Better  Practices  but  Is  Not  Consistently  Applied”  (GAO-09-630,  available  at 
http://www.gao.gov/new.items/d09630.pdf).  The  report  reviewed  the  award  fee  practices 
of  five  government  agencies,  including  the  Department  of  Defense — that  accounted  for 
over  95  percent  of  dollars  spent  on  award  fee  contracts  in  2008.  This  GAO  review  was 
conducted  in  light  of  Office  of  Management  and  Budget  (OMB)  December  2007 
guidance  on  the  “Appropriate  Use  of  Incentive  Contracts”  (available  at 
http://www.whitehouse.gov/omb/assets/omb/procurement/memo/incentive_contracts_120 
407.pdf). 

The  OMB  memo  espoused  principles  for  applying  award  fees  such  as  (1)  limiting  the 
opportunities  for  earning  unearned  fees  in  subsequent  periods  (fee  rollover);  (2)  linking 
award  fees  to  acquisition  outcomes;  (3)  designing  evaluation  criteria  to  motivate 
excellent  performance;  and  (4)  not  paying  for  unsatisfactory  perfonnance.  GAO  found 
that  DoD’s  updated  guidance  largely  reflects  these  principles  and  that  it  now  prohibits 
payment  of  award  fees  for  unsatisfactory  performance.  In  addition,  it  found  that  DoD 
will  save  more  than  $450  million  by  not  routinely  offering  contractors  a  second  chance  at 
unearned  fees  and  $68  million  by  using  more  clearly  defined  evaluation  criteria. 

In  addition,  the  report  cites  other  important  guidance,  such  as  the  Federal  Acquisition 
Regulations  (FAR),  which  advise  that  “an  award  fee  should  be  used  when  the  work  to  be 
performed  is  such  that  it  is  neither  feasible  nor  effective  to  devise  predetermined 
objective  incentive  targets  applicable  to  cost,  technical  performance,  or  schedule.”  It  also 
reiterates  the  OMB  guidance  that  “it  is  imperative  that  award  fees  are  linked  to  desired 
outcomes  such  as  discrete  events  or  milestones.  Such  milestones  include  design  reviews 
and  system  demonstrations  for  weapons  systems.” 

In  April  2007,  DoD  provided  additional  guidance  on  contracting  incentives, 
“[rjecognizing  that  most  DOD  contracts  contain  objective  criteria,  the  guidance  clarified 
that  in  instances  where  objective  criteria  exist  and  the  Contracting  Officer  and  Program 
Manager  wish  to  also  evaluate  and  incentivize  subjective  elements  of  performance,  the 
most  appropriate  contract  type  would  be  a  multiple  incentive  type  contract  containing 
both  incentive  and  award  fee  criteria.” 
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As  part  of  the  Naval  OA  effort,  we  recommend  the  OMB  and  DoD  guidance  cited  in  this 
GAO  report  be  followed  to  help  programs  reap  the  benefits  of  properly  motivating 
contractors.  The  Office  of  Management  and  Budget’s  Office  of  Federal  Procurement 
Policy  Incentive  Contract  Checklist  is  available  from  the  OMB  website  at 
http://www.whitehouse.gov/omb/assets/omb/procurement/memo/incentive  contracts  120 

407.pdf 

Although  the  Guidebook  was  developed  for  mixed  systems  comprised  of  hardware, 
middleware  and  software  elements,  the  recommended  language  can  be  easily  tailored  to 
reflect  hardware-  or  software-only  acquisitions. 

For  additional  guidance,  refer  to  Office  of  the  Under  Secretary  of  Defense  (Acquisition, 
Testing,  and  Logistics  (OUSD(AT&L)/DPAP)  policy  memo  dealing  with  “Proper  use  of 
Award  Fee  Contracts  and  Award  Fee  provisions”  available  at: 
http://www.acq.osd.mil/dpap/policv/policyvault/2007-0197-DPAP.pdf. 

The  following  is  guidance  for  developing  a  contract  Incentive  Plan  for  a  program  seeking 
to  implement  Naval  Open  Architecture  principles.  Additional  information  is  found  in  the 
Department  of  Defense’s  Open  Systems  Joint  Task  Force  (OSJTF)  Modular  Open 
Systems  Approach  (MOSA)  to  acquisition. 

This  chapter  is  intended  to  serve  as  a  guide  for  those  programs  seeking  to  incentivize 
their  contractors  to  implement  Naval  Open  Architecture  business  and  technical  principles 
in  both  development  and  production  contracts.  The  award  fee  criteria  are  drawn  from  the 
business  and  technical  principles  embodied  in  the  MOSA  principles  and  OUSD 
(AT&L)’s  draft  guide.  The  Award  Term  recommendations  are  based  on  contracting 
practices  that  have  been  used  in  the  Army,  Air  Force,  SPAWAR  and  NAVSEA  (on  the 
Seaport  contract  vehicle  and  Submarine  Warfare  Federated  Tactical  System  contract). 
Award  Terms  are  particularly  appropriate  for  service  and  support  contracts  but  are  worth 
considering  for  other  types  of  contracts  for  such  functions  as  integration,  test,  and 
installation. 

Part  1  Award  Fees 

For  “Performance  and  Schedule”  portion  of  the  Award  Fee  Plan,  the  Government  shall 
apply  the  following  OA-related  award  fee  criteria: 

•  Incorporation  of  considerations  for  reconfigurability,  portability, 
maintainability,  technology  insertion,  vendor  independence,  reusability, 
scalability,  interoperability,  upgradeability,  and  long-term  supportability  as 
defined  by  Naval  Open  Architecture. 

•  Implementation  of  a  layered  and  modular  system  that  makes  maximum  use  of 
non-proprietary  Commercial-Off-the-Shelf  /  Non-developmental  Item 
(COTS/reusable  NDI)  hardware,  software,  operating  systems,  and 
middleware. 
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•  Minimization  of  inter-component  dependencies  and  ability  to  allow 
components  to  be  decoupled  and  re-used,  where  appropriate. 

•  Early  and  often  disclosure  of  data  related  to  the  design  of  designated 
components  or  subcomponents. 

•  Adaptability  to  evolving  requirements  and  threats. 

•  Modularity  of  products. 

•  Use  of  open,  standards-based  interfaces. 

•  Interoperability  with  joint  warfighting  applications  and  secure  information 
exchange. 

•  Reduction  of  development  cycle  time  and  total  life-cycle  cost. 

•  Commonality  and  reuse  of  components  within  the  system.  Emphasis  should 
be  placed  on  reuse  of  components  (software,  middleware,  applications 
software,  algorithms,  etc.)  from  the  pertinent  Navy  and  Marine  Corps 
community  of  interest  as  a  means  of  facilitating  maintenance  and  upgrades. 

•  Identification  of  potential  candidates  for  reuse  from  outside  the  contractor’s 
own  organization  for  inclusion  in  selection  of  design  alternatives. 

•  Enabling  rapid  technology  insertion. 

For  “Work  Relations”  portion  of  the  Award  Fee  Plan,  the  Government  shall  apply  the 
following  OA-related  criteria; 

•  Collaboration  with  the  Government,  contractors  and  Vendors  to  develop  a 
highly  performing  system. 

•  Working  with  the  Government,  contractors  and  Vendors  to  incorporate 
revised  schedules  and  meet  changing  Government  requirements. 

•  Identification  of  and  working  with  contractors  and  Vendors  to  improve 
PROGRAM  X  perfonnance. 

•  Identification  and  incorporation  of  innovative  methods  with  contractors  and 
Vendors  to  provide  development  assets  without  procuring  unique  assets. 

•  Identification  of  and  working  with  contractors  and  Vendors  who  possess 
innovative  technologies  and  methods. 

•  Working  with  contractors  and  Vendors  to  identify  new  technology  and 
functionality. 

•  Working  with  contractors  and  Vendors  to  identify  innovative  ways  to 
incorporate  new  technology  that  improves  perfonnance. 

•  Working  with  contractors  and  Vendors  to  mitigate  the  risks  associated  with 
technology  obsolescence,  being  locked  into  proprietary  or  vendor-unique 
technology,  and  reliance  on  a  single  source  of  supply  over  the  life  of  a  system. 

Alternatively,  a  Program  Manager  may  want  to  structure  award  fees  around  four  different 
categories;  (1)  Cost,  (2)  Schedule,  (3)  Management,  and  (4)  Technical  attributes.  This 
provides  a  different  kind  of  flexibility  where  each  category  can  be  given  a  different 
emphasis  by  giving  it  a  percentage  weight  of  the  award  fee  total.  For  example,  10%, 
20%,  30%,  and  40%,  respectively,  would  hold  technical  attributes  as  the  most  important 
and  cost  as  the  least  important.  Additionally,  from  an  OA  perspective,  a  PM  will  want  to 
include  the  following  language  under  “Technical”: 
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The  contractors  will  be  evaluated  on  whether  the  technical  data  rights  submitted  with 
the  deliverable  support  the  Naval  Open  Architecture  (OA)  principles,  including 
minimizing  proprietary  elements,  without  unjustified  or  inappropriate  limitations  on 
rights  or  use  by  the  Government. 

Part  2  Award  Terms 

An  award  term  incentive  contract  is  a  relatively  new  acquisition  option  and  while  it  is  not 
yet  described  in  the  Federal  Acquisition  Regulation  (FAR)  or  Defense  Federal 
Acquisition  Regulation  Supplement  (DFARS)  it  is  modeled  after  the  award  fee  incentive 
described  in  FAR  16.405-2  and  DFARS  216.405-2.  Being  that  award  tenn  incentives 
relate  closely  with  those  of  award  fee,  the  guidance  described  in  Chapter  D  of  this 
Guidebook  are  directly  applicable  and  will  not  be  restated  in  this  chapter.  Rather,  an 
explanation  of  the  award  term  contract  and  recommendations  for  establishing  an  Award 
Term  Plan  is  provided.  Program  Managers  should  weigh  the  benefits  of  using  award 
terms  against  the  value  of  frequent  competitions  to  encourage  innovation  and  exceptional 
performance. 

Contract  Premise:  Instead  of  rewarding  the  contractor  with  additional  fee  for 
exceptional  performance  the  award  term  contract  rewards  the  contractor  by  extending  the 
contract  period  of  performance  in  the  form  of  additional  term  periods  added  on  to  the 
basic  contract.  Under  an  award  term  incentive  the  Government  monitors  and  evaluates 
the  contractor’s  performance,  and  if  it  is  decided  that  the  contractor’s  perfonnance  was 
excellent,  then  the  contractor  earns  an  extension.  During  subsequent  evaluations  if  the 
contractor  maintains  excellent  performance  additional  tenns  are  awarded.  If  the 
contractor’s  perfonnance  decreases,  the  possibility  of  the  contractor  not  being  awarded  an 
additional  term  or  even  having  terms  previously  awarded  taken  away  is  the  incentive  for 
the  contractor  to  perform  at  an  exceptional  level.  The  additional  terms  are  not  option 
periods  but  extensions  to  the  contract.  This  distinguishes  the  award  term  contract  from 
other  incentive  type  contracts  in  that  if  the  contractor  meets  the  award  term  criteria 
outlined  in  the  contract,  and  if  all  other  stipulated  conditions  such  as  continuing  need  and 
availability  of  funds  are  met,  then  the  Government  must  either  extend  the  contract  or 
tenninate  it  for  convenience  or  default. 

Example  of  an  Award  Term  Contract  Timeline.  A  competitive  contract  is  awarded 
consisting  of  a  base  year  plus  four  (4)  one-year  options.  During  the  base  year  the 
contractor’s  performance  is  evaluated  and,  depending  on  how  the  Award  Term  Plan  is 
structured,  the  initial  evaluation  can  either  be  for  informational  purposes  only  or  it  can  be 
a  formal  evaluation  in  which  contractor  perfonnance  determines  the  awarding  of  an 
award  term  (at  this  point  no  award  tenns  can  be  lost  since  the  contractor  has  yet  to  earn 
one).  Since  the  basic  contract  is  for  five  years  (where  an  evaluation  is  conducted  for  each 
of  those  years)  the  contractor  could  be  rewarded  with  up  to  five  additional  year  long 
extensions  to  the  basic  contract  for  a  total  of  10  years  maximum. 

Considerations: 
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•  It  is  highly  recommended  that  mid-year  reviews  be  conducted  that  will  provide 
informational  feedback  to  the  contractor  on  perfonnance. 

•  The  structure  of  the  contract  period  of  performance  is  flexible  within  the  boundaries 
established  by  the  FAR/DFARS.  For  example,  Award  Tenn  Review  Board  (ATRB) 
reviews  could  be  conducted  annually  or  semiannually;  base  and  option  years,  number 
of  award  tenns,  etc.,  are  at  the  discretion  of  the  contracting  office. 

•  Evaluation  criteria  are  at  the  discretion  of  the  contracting  officer  and  program  office 
administering  the  contract  and  could  include  evaluations  for  cost,  schedule,  technical 
performance,  customer  satisfaction,  etc.  It  is  the  policy  of  the  Department  of  Defense 
that  objective  criteria  be  utilized,  whenever  possible,  to  measure  contract 
performance. 

•  Within  the  evaluation  criteria  it  is  recommended  that  the  government’s  expectation  of 
how  the  contractor  will  be  evaluated  in  implementing  Naval  Open  Architecture  be 
clearly  defined  (using  the  same  considerations  as  those  identified  in  Chapter  D  for 
award  fee  contracts). 

Award  Term  Plan  Structure:  There  is  no  mandated  format  for  an  award  tenn  plan.  It 

is  recommended  that  the  structure,  however,  include  the  following  components; 

•  A  cover  sheet  that  identifies  the  Award  Term  Plan  (ATP)  as  an  attachment  to  the 
formal  contract  with  signature  blocks  included  for  the  Procuring  Contracting  Officer 
(PCO)  and  the  Term  Determining  Official  (TDO); 

•  Table  of  Contents; 

•  An  Introduction  section  that  describes  the  overall  objectives  of  the  ATP  and  how  it 
relates  to  the  requirements  in  the  Statement  of  Work  (SOW); 

•  A  section  that  describes  the  organization  (Award  Term  Review  Board  (ATRB),  TDO, 
etc.)  and  responsibilities  of  the  board  and  its  members; 

•  A  description  of  the  award  tenn  process; 

•  A  description  of  how  changes  to  the  ATP  will  be  addressed;  and 

•  Annexes  to  the  ATP  should  include: 

o  Members  of  the  ATRB  (by  government  code  -  not  by  name) 
o  A  time  line  for  award  tenn  evaluation  periods 
o  Evaluation  Criteria 
o  Example  of  the  assessment  form(s). 
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Appendix  1:  RECOMMENDED  NOA  CDRL  AND  DELIVERABLE 

ITEMS 


The  following  are  examples  of  Contract  Data  Requirements  Lists  (CDRLs)  and 
deliverable  items  that  support  NOA  and  can  be  incorporated  into  contracts.  This  is  not 
intended  to  be  an  exhaustive  list  of  all  potential  deliverable  items,  but  is  an  attempt  to  list 
only  those  deliverables  we  believe  significantly  support  Naval  Open  Architecture,  and 
can  be  augmented/reduced  as  the  Program  Manager  believes  is  appropriate.  The 
frequency  and  delivery  dates  of  the  deliverables  must  be  specified,  along  with  a  list  of 
deliverable  recipients. 

Deferred  Ordering  of  Technical  Data  or  Computer  Software  (Including  Design  and 
Development  Artifacts) 

DFARS  227.7103-8(b)  DEFERRED  DELIVERY  AND  DEFERRED  ORDERING 
OF  TECHNICAL  DATA 

(b)  Deferred  Ordering.  Use  the  clause  at  252.227-7027,  Deferred  Ordering  of  Technical 
Data  or  Computer  Software,  when  a  firm  requirement  for  a  particular  data  item(s)  has  not 
been  established  prior  to  contract  award  but  there  is  a  potential  need  for  the  data.  Under 
this  clause,  the  contracting  officer  may  order  any  data  that  has  been  generated  in  the 
performance  of  the  contract  or  any  subcontract  thereunder  at  any  time  until  three  years 
after  acceptance  of  all  items  (other  than  technical  data  or  computer  software)  under  the 
contract  or  contract  termination,  whichever  is  later.  The  obligation  of  subcontractors  to 
deliver  such  data  expires  three  years  after  the  date  the  contractor  accepts  the  last  item 
under  the  subcontract.  When  the  data  are  ordered,  the  delivery  dates  shall  be  negotiated 
and  the  contractor  compensated  only  for  converting  the  data  into  the  prescribed  form, 
reproduction  costs,  and  delivery  costs. 


Software  Development  Process16 

The  software  development  process  to  be  used  by  the  winning  contractor  team  is  to  be 
defined  and  documented  in  the  developer’s  SDP  which  shall  be  designated  as  a  CDRL. 
Contractor  teams  are  to  submit  an  initial  delivery  of  the  SDP  with  the  proposal.  After 
contract  award,  an  updated  version  is  to  be  delivered  based  on  discussion  and 
negotiations  with  the  Government  regarding  approval  of  SDP  content. 

In  accord  with  DoN  policy,  the  SDP  is  to  confonn  to  the  framework  established  in 
IEEE.EIA  12207,  with  the  content  as  required  in  ASN(RD&A)  Memo  Nov.  17,  2006 
titled,  “Software  Process  Improvement  Initiative  Contract  Language,”  and  ASN(RD&A) 


16  Assistant  Secretary  of  the  Navy  (Research,  Development  and  Acquisition)’ s 
Memorandum  on  “Software  Process  Improvement  Initiative  Contract  Language,”  dated 
November  17,  2006. 
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Memo  July  13,  2007  titled,  “Software  Process  Improvement  Initiative  (SPII)  Guidance 
for  Use  of  Software  Process  Improvement  Contract  Language.”  The  fonnat  of  the  SDP 
can  be  contractor-selected,  but  can  be  required  to  follow  the  format  as  defined  in 
Appendix  L  of  the  SPII  Guidebook. 

Specifically,  the  SDP  should: 

•  Document  all  processes  applicable  to  the  system  to  be  acquired,  including  the 
Primary,  Supporting,  and  Organizational  life  cycle  processes  as  defined  by 
IEEE/EIA  Std.  12207  as  appropriate. 

•  Contain  the  content  defined  by  all  infonnation  items  listed  in  Table  1  of 
IEEE/EIA  Std.  12207.1,  as  appropriate  for  the  system  and  be  consistent  with  the 
processes  proposed  by  the  developers.  If  any  information  item  is  not  relevant  to 
either  the  system  or  to  the  proposed  process,  that  item  need  not  be  required. 

•  Adhere  to  the  characteristics  defined  in  section  4.2.3  of  IEEE/EIA  Std.  12207,  as 
appropriate. 

•  Contain  information  at  a  detail  sufficient  to  allow  the  use  of  the  SDP  as  the  full 
guidance  for  the  developers.  In  accordance  with  section  6.5.3a  of  IEEE/EIA  Std. 
12207.1,  it  should  contain,  “specific  standards,  methods,  tools,  actions,  reuse 
strategy,  and  responsibility  associated  with  the  development  and  qualification  of 
all  requirements,  including  safety  and  security.” 


Naval  Open  Architecture  Products 

It  is  recommended  that  the  Program  Office  perform  an  assessment  of  its  Intellectual 
Property  Rights  needs  and  craft  its  CDRL  and  Deliverable  requirements  accordingly.  If 
the  Program  Office,  PEO,  Domain  or  Sponsor  believes  that  the  program  deliverables 
would  be  of  such  interest  that  they  warrant  inclusion  in  the  appropriate  repository  (such 
as  Surface’s  SHARE  or  PEO  C4I’s  NESI)  then  the  CDRL  and  deliverables  should 
include  those  design,  developmental,  or  diagnostic  items  needed  to  reproduce  or  recreate 
the  asset. 

The  ideal  asset  would  have  artifacts  in  most  or  all  of  the  following  categories.  The  key  to 
obtaining  these  artifacts  is  to  require  that  they  be  delivered  as  part  of  the  terms  of  the 
contract.  These  deliverables  must  be  delivered  with  Government  Purpose  Rights  (GPR) 
if  they  are  to  be  added  to  a  Government  repository.  In  order  to  facilitate  reuse,  the  asset 
should  bundle  the  following  or  their  equivalent: 

•  Requirements  (e.g.,  Word  documents,  DOORS  file  or  Excel  or  XML  export) 

•  Architecture  models  (e.g.,  System  Architect  files,  including  DoDAF  views  where 
required) 

•  Functional  models  (e.g.,  CORE  file  in  native  format  or  XML  export)  Software 
models  (e.g.,  Rose/Rhapsody/iUML  (Unified  Modeling  Language)/ Artisan 
models  in  native  or  XMI  format;  minimum  diagrams  Class  and  State  or 
Interaction/  S  equenc  e) 
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•  Hardware  models  (e.g.,  CAD  DXF,  IEGS  fdes) 

•  Human  systems  engineering  models  (e.g.,  IPME  or  Envision  Ergo  files) 

•  Cost  models  (e.g.,  PRICE,  SEER,  COMET,  VAMOSC,  Excel  files) 

•  Modeling  and  Simulation  data  (e.g.,  NETWARS/OPNET,  NSS,  GCAM  - 
scenarios,  environmental,  platforms,  tactics,  MOEs,  MOPs  in  XMI  format 
following  JC3IEDM  or  XMSF  standards) 

•  Test  plans  and  results  (e.g.,  QA  Run,  Quality  Center  files  or  Word  or  Excel 
export) 

•  Logistics  data  (e.g.,  COMPASS,  CASA,  PowerLOG  in  native  or  XML/CSV 
format) 


Recommended  NOA  CDRL  and  Deliverable  Items 

The  following  recommended  deliverables  for  open  architecture  systems  have  official 
Deliverable  Item  Descriptions  (DIDs)  accepted  by  the  Department  of  Defense’s  Defense 
Standardization  Program.  The  official  DIDs  are  available  from  the  Document 
Automation  and  Production  Service  (DAPS)  Acquisition  Streamlining  and 
Standardization  Infonnation  System  (ASSIST)  database  at  http://assist.daps.dla.mil.  To 
obtain  these  DIDs  simply  search  the  database  using  either  the  DID’s  title  or  its  ID 
number  listed  below  in  the  brief  descriptions. 

1.  Software  Development  Plan  (SDP):  The  SDP  describes  a  developer’s  plans  for 
conducting  a  software  development  effort.  The  term  “software  development”  is 
meant  to  include  new  development,  modification,  reuse,  reengineering,  maintenance, 
and  all  other  activities  resulting  in  software  products.  [DID  ID:  DI-IPSC-81427A] 

2.  Software  Requirements  Specification  (SRS):  The  SRS  specifies  the  requirements  for 
a  Computer  Software  Configuration  Item  (CSCI)  and  the  methods  to  be  used  to 
ensure  that  each  requirement  has  been  met.  Requirements  pertaining  to  the  CSCI’s 
external  interfaces  may  be  presented  in  the  SRS  or  in  one  or  more  Interface 
Requirements  Specifications  (IRSs)  (DI-IPSC-81434A)  referenced  from  the  SRS. 
[DID  ID:  DI-IPSC-81433A]  It  has  also  been  defined  as  a  complete  description  of  the 
behavior  of  the  software  to  be  developed.  It  includes  a  set  of  use  cases  that  describe 
all  of  the  interactions  that  the  users  will  have  with  the  software.  It  also  contains 
functional  requirements,  which  define  the  internal  workings  of  the  software:  that  is, 
the  calculations,  technical  details,  data  manipulation  and  processing,  and  other 
specific  functionality  that  shows  how  the  use  cases  are  to  be  satisfied.  It  also  contains 
nonfunctional  requirements,  which  impose  constraints  on  the  design  or 
implementation  (such  as  performance  requirements,  quality  standards  or  design 
constraints).  [Stellman  &  Greene  Consulting;  http://www.stellman-greene.com1 

3.  Software  Version  Description  (SVD):  The  Software  Version  Description  (SVD) 
identifies  and  describes  a  software  version  consisting  of  one  or  more  Computer 
Software  Configuration  Items  (CSCIs).  It  is  used  to  release,  track,  and  control 
software  versions.  [DID  ID:  DI-IPSC-81442A] 
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4.  Software  Product  Specification  (SPS):  The  SPS  contains  or  references  the  executable 
software,  source  files,  and  software  support  information,  including  “as  built”  design 
information  and  compilation,  build,  and  modification  procedures,  for  a  Computer 
Software  Configuration  Item  (CSCI).  [DID  ID;  DI-IPSC-81441A]  It  is  the  detailed 
design  and  description  of  Software  Items  (Sis)  comprising  the  product  baseline. 
Analogous  to  the  Item  Detail  Specification  of  a  hardware  Configuration  Item  (Cl)  in 
the  product  baseline  of  a  hardware  system.  [Defense  Acquisition  University] 

5.  Software  Installation  Plan  (SIP);  The  SIP  is  a  plan  for  installing  software  at  user 
sites,  including  preparations,  user  training,  and  conversion  from  existing  systems. 
[DID  ID;  DI-IPSC81428A] 

6.  Software  Test  Plan  (STP):  The  Software  Test  Plan  (STP)  describes  plans  for 
qualification  testing  of  Computer  Software  Configuration  Items  (CSCIs)  and  software 
systems.  It  describes  the  software  test  environment  to  be  used  for  the  testing, 
identifies  the  tests  to  be  perfonned,  and  provides  schedules  for  test  activities.  There 
is  usually  a  single  STP  for  a  project.  The  STP  enables  the  acquirer  to  assess  the 
adequacy  of  planning  for  CSCI  and,  if  applicable,  software  system  qualification 
testing.  [DID  ID;  DI-IPSC-81438A] 

7.  Software  Test  Report  (STR):  The  Software  Test  Report  (STR)  is  a  record  of  the 
qualification  testing  performed  on  a  Computer  Software  Configuration  Item  (CSCI),  a 
software  system  or  subsystem,  or  other  software-related  item.  The  STR  enables  the 
acquirer  to  assess  the  testing  and  its  results.  [DID  ID;  DI-IPSC-81440A] 

8.  Software  Test  Description;  The  Software  Test  Description  (STD)  describes  the  test 
preparations,  test  cases,  and  test  procedures  to  be  used  to  perform  qualification  testing 
of  a  Computer  Software  Configuration  Item  (CSCI)  or  a  software  system  or 
subsystem.  [DID  ID:  DI-IPSC-81439A] 

9.  Software  Design  Description:  The  Software  Design  Description  (SDD)  describes  the 
design  of  a  Computer  Software  Configuration  Item  (CSCI).  It  describes  the  CSCI- 
wide  design  decisions,  the  CSCI  architectural  design,  and  the  detailed  design  needed 
to  implement  the  software.  The  SDD  may  be  supplemented  by  the  Interface  Design 
Descriptions  (IDDs)  and  Database  Design  Descriptions  (DBDDs).  [DID  ID;  DI- 
IPSC-81435A] 

10.  Interface  Requirements  Specification:  The  Interface  Requirements  Specification 
(IRS)  specifies  the  requirements  imposed  on  one  or  more  systems,  subsystems, 
Hardware  Configuration  Items  (HWCIs),  Software  Configuration  Items  (SWCIs), 
manual  operations,  or  other  system  components  to  achieve  on  or  more  interfaces 
among  these  entities.  [DID  ID;  DI-IPSC-81434A] 

11.  Software  Transition  Plan  (STrP):  The  developer  shall  identify  all  software 
development  resources  that  will  be  needed  by  the  support  agency  to  fulfill  the  support 
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concept  specified  in  the  contract.  The  developer  shall  develop  and  record  plans 
identifying  these  resources  and  describing  the  approach  to  be  followed  for 
transitioning  deliverable  items  to  the  support  agency.  [DID  ID:  DI-IPSC-81429A] 

12.  Interface  Design  Description:  An  Interface  Design  Description  (IDD)  describes  the 
interface  characteristics  of  one  or  more  systems,  subsystems,  hardware  configuration 
items  (HWCIs),  computer  software  configuration  items  (CSCIs),  manual  operations, 
or  other  system  components.  [DID  ID:  DI-IPSC-81436A] 

13.  Data  Accession  List  (DAL):  The  purpose  of  the  DAL  is  to  provide  a  medium  for 
identifying  contractor  internal  data  which  has  been  generated  by  the  contractor  in 
compliance  with  the  work  effort  described  in  the  Statement  of  Work  (SOW).  The 
DAL  is  an  index  of  the  generated  data  that  is  made  available  upon  request.  [DID  ID: 
DI-MGMT-8 1453A] 

14.  Computer  Software  Product  End  Items:  Provides  data  formatted  for  review  or 
maintenance  to  ensure  significant  milestones  are  met.  Data  produced  under  this 
requirement  will  be  used  during  the  life  cycle  for  development,  operation  and 
maintenance.  [DID  ID:  DI-MCCR-80700] 

15.  Product  Drawings/Models  and  Associated  Lists:  These  data  items  provide 
engineering  data  to  support  competitive  procurement  and  maintenance  for  items 
interchangeable  with  the  original  items.  This  data  represents  the  highest  level  of 
design  disclosure.  [DID  ID:  DI-SESS-81000C] 

16.  Commercial  Drawings/Models  and  Associated  Lists:  These  data  items  define 
commercial  items  acquired  by  the  Department  of  Defense.  [DID  ID:  DI-SESS- 
81003C] 

17.  Drawing  Number  Assignment  Report:  This  data  item  provides  the  infonnation 
necessary  to  maintain  the  Government’s  drawing  number  usage  records.  [DID  ID: 
DI-SESS-8101 1C] 

18.  Proposed  Critical  Manufacturing  Process  Description  (PCMPD):  The  PCMPD 
identifies  processes  which  are  proposed  for  inclusion  in  the  technical  data  package 
(TDP)  as  mandatory  to  meet  the  engineering  requirements  of  the  item  or  component 
part  thereof  for  which  the  TDP  is  being  prepared.  [DID  ID:  DI-81012C] 

19.  Special  Inspection  Equipment  (SIE)  Drawings/Models  and  Associated  Lists:  These 
data  items  provide  the  data  required  for  the  limited  production  of  SIE  which 
duplicates  the  physical  and  perfonnance  characteristics  of  the  original  SIE.  [DID  ID: 
DI-SESS-81004C] 

20.  Special  Tooling  (ST)  Drawings/Models  and  Associated  Lists:  These  data  items 
provided  the  data  required  for  the  limited  production  of  ST  which  duplicates  the 
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physical  and  performance  characteristics  of  the  original  ST.  [DID  ID;  DI-SESS- 
81008C] 

2 1 .  Source  Control  Drawing  Approval  Request:  This  data  item  provides  the  Government 
with  a  means  for  approving  and  disapproving  the  use  of  source  control  drawings  for 
specific  items  selected  for  use  in  the  equipment.  [DID  ID:  DI-SESS-81010C] 

22.  Detail  Specification  Documents:  A  detail  specification  will  be  used  to  specify  design 
requirements  for  items  used  in  multiple  programs  or  applications,  in  terms  of 
materials  to  be  used,  how  a  requirement  is  to  be  achieved  or  how  an  item  is  to  be 
fabricated  or  constructed.  Detail  specification  documents  are  intended  for  reference 
in  acquisition  contracts.  [DID  ID:  ID-SDMP-81464A] 

23.  Program-Unique  Specification  Documents:  A  program-unique  specification  will  be 
used  to  specify  functional  and  perfonnance  requirements  and,  where  applicable, 
design  solutions  for  systems,  items,  software,  processes,  and  materials  developed  and 
manufactured  for  use  with  a  single  system,  product,  or  application.  Requirements  are 
stated,  as  applicable,  in  terms  of  required  results,  the  environment  in  which  it  must 
operate,  interface,  and  interchange  characteristics;  materials  to  be  used;  how  the  item 
is  to  be  fabricated  or  constructed;  and  criteria  for  verifying  compliance.  Program- 
unique  specification  documents  are  intended  for  reference  in  contracts.  [DID  ID:  ID- 
SDMP-81493] 

24.  Integrated  Master  Schedule  (IMS):  The  IMS  is  an  integrated  schedule  containing  the 
networked,  detailed  tasks  necessary  to  ensure  successful  program  execution.  The  IMS 
is  vertically  traceable  to  the  Integrated  Master  Plan  (IMP)  (if  applicable),  the  Contract 
Work  Breakdown  Structure  (CWBS),  and  the  Statement  of  Work  (SOW).  The  IMS 
shall  be  used  to  verify  attainability  of  contract  objectives,  to  evaluate  progress  toward 
meeting  program  objectives,  and  to  integrate  the  program  schedule  activities  with  all 
related  components.  This  DID  is  applicable  to  development,  major  modification,  and 
low  rate  initial  production  efforts;  it  is  not  typically  applied  to  full  rate  production 
efforts.  [DID  ID:  DI-MGMT-81650] 

25.  Reuse  Management  Report  (ReMR):  The  Reuse  Management  Report  (ReMR) 
provides  information  about  existing  software  products  intended  to  be  re-used  as-is  or 
modified  as  part  of  the  delivered  operational  software.  The  report  also  provides  the 
acquirer  insight  into  the  current  status  of  the  activities  associated  with  the  reuse  of 
these  products  as  compared  to  the  planned  activities,  and  alternative  approaches. 

[DID  ID:  DI-SESS-81771] 

The  following  recommended  deliverables  for  open  architecture  systems  do  not  have 
official  Data  Item  Descriptions  (DIDs)  maintained  by  DoD.  However,  we  have  listed 
them  and  provided  brief  descriptions  to  help  programs  understand  the  additional  types  of 
data  they  should  acquire  during  system  acquisition: 
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1 .  An  Open  System  Management  Plan  addressing  architecture  openness  that  describes, 
but  is  not  limited  to;  the  Offeror’s  approach  to  open  system  architecture,  modular, 
open  design;  inter-component  dependencies;  design  infonnation  documentation; 
technology  insertion;  life-cycle  sustainability;  interface  design  and  management; 
treatment  of  proprietary  or  vendor-unique  elements;  and,  reuse  of  pre-existing  items 
including  all  Commercial-Off-the-Shelf/Non-developmental  Item  (COTS/ND I) 
components,  their  functionality  and  proposed  function  in  the  system,  and  copies  of 
license  agreements  related  to  the  use  of  these  components  for  Government  approval. 
The  open  system  management  plan  shall  also  include  a  statement  explaining  why 
each  COTS/NDI  was  selected  for  use.  The  initial  plan  shall  be  submitted  with  the 
CDRL. 

2.  Results  of  [ periodic  or  milestone-based]  NOA  assessments  using  Government- 
specified  tools  and  methodologies  (e.g.,  OAAT  or  MOSA  PART). 

3.  Results  of  [ periodic  or  milestone-based]  market  surveys  conducted  to  identify 
candidate  Government  IP  assets,  COTS  and  other  reusable  NDI  capable  of  achieving 
the  perfonnance  requirements  of  solutions  that  it  has  proposed  to  custom  build. 

4.  [ Semi-annual ,  annual,  etc.]  Naval  Open  Architecture-related  updates  to  the  System 
Management  Plan. 

5.  Results  of  regular  [semi-annual,  annual,  etc.]  reviews  of  the  contractor’s  plan  for 
addressing  exceptions  to  reuse. 

6.  Results  of  regular  [semi-annual,  annual,  etc.]  reviews  of  the  contractor’s  plan  for 
addressing  (and  minimizing  the  use  of)  proprietary  or  vendor-unique  elements. 

7.  Documented  results  of  product  demonstrations  that  exhibit  the  OA  aspects  of  the 
system  or  component. 

8.  Regular  [semi-annual,  annual,  etc.]  review  and  update  of  the  contractor’s  rationale 
for  the  modularization  choices  made  to  generate  the  design.  These  updates  shall 
explicitly  address  any  tradeoffs  performed,  particularly  those  that  compromise  the 
modular  and  open  nature  of  the  system. 

9.  Documents  that  provide  a  detailed  tracing  of  all  system  requirements  (including  those 
contained  in  the  Initial  Capabilities  Document,  Capabilities  Development  Document, 
and  in  Section  C  of  this  Solicitation)  to  one  or  more  design  modules.  [See  Section  L, 
Paragraph  1,  subparagraph  c.] 

10.  The  Offeror  shall  provide  documentation  demonstrating  that  their  system  design 
meets  MOSA  and  other  requirements  identified  in  Section  C/SOW  and  can  facilitate 
component  reuse  by  conducting  a  series  of  demonstrations. 
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1 1 .  The  Offeror  shall  deliver  a  notional  test  plan,  test  protocol,  test  design,  testing 
software,  testing  tools,  etc.,  necessary  to  support  the  independent  Government  testing 

and  assessment  of  the _ components  and  demonstration  of  the 

interoperability  of  the  components. 

12.  The  Offeror  shall  deliver  to  the  Government,  specifically  the  activity _ a 

copy  of  the _ software  application(s)  including  all  testing  devices, 

testing  software,  results  and  materials,  along  with  all  supporting  documentation,  for 
the  Government  to  use  for  testing. 

13.  The  Offeror  will  develop  and  maintain  a  Common  Data  Model  for  the  system  and 
will  provide  the  Government  with  updates  at  [monthly,  quarterly,  etc.]  intervals. 

14.  Executable  source  code  and  binaries  (including  the  specified  programming  languages, 
libraries,  and  tools). 

15.  Package  description;  makefiles.  “Makefiles”  is  a  set  of  software  code  that  perfonns  a 
set  of  actions  in  a  sequence.  Normally  a  “makefile”  is  a  (plain  text)  script  file  that  a 
compiler  uses  to  compile  and  link  files  to  make  an  executable.  The  file  lets  the 
compiler  know  the  order  to  compile.  Specifically,  “make”  is  a  command  to  use  the 
makefile  to  compile  a  C++  file.  For  example,  Java  uses  a  program  called  Ant 
(http://ant.apache.org/)  which  uses  an  XML  file  to  do  the  same  thing. 

16.  Environment  description. 

17.  Ownership  /  licensing  and  permission  information. 

18.  Installation  script  files  in  uncompressed  segment  installer  fonnat. 

19.  Software  test  programs  and  source  code,  including  tools. 

20.  Software  and  system  test  report(s),  test  data  (if  available)  and  test  metrics,  including 
“bug  reports.” 

2 1 .  Software  Development  File  (SDF):  A  repository  for  material  pertinent  to  the 
development  of  a  particular  body  of  software.  Contents  typically  include  (either 
directly  or  by  reference)  considerations,  rationale,  and  constraints  related  to 
requirements  analysis,  design,  and  implementation;  developer-internal  test 
information;  and  schedule  and  status  information. 
[http://sepo.spawar.navy.mil/SDF.doc] 

22.  Software  Test  Procedures:  The  Software  Test  Procedure  describes  plans  for 
qualification  testing  of  Computer  Software  Configuration  Items  (CSCIs)  and  software 
systems.  [Pogner] 
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23.  Software  Users  Manual  (SUM):  The  Software  User  Manual  (SUM)  tells  a  hands-on 
software  user  how  to  install  and  use  a  Computer  Software  Configuration  Item  (CSCI), 
a  group  of  related  CSCIs,  or  a  software  system  or  subsystem.  [University  of 
Massachusetts;  http://www2.umassd.edu/SWPI/DOD/MIL-STD-498/SUM- 
DID.PDF1 

24.  Waveform:  A  waveform  is  the  representation  of  a  signal  as  a  plot  of  amplitude 
versus  time.  [DAU] 

25.  Design  Specification:  A  design  specification  provides  detailed  description  of  the 
design.  It  uses  data  flow  diagrams  or  other  data  representations  developed  during 
requirements  analysis  and  refined  during  design  to  derive  software  structure. 
[University  of  Southern  California; 

http  ://sunset.usc .  edu/classes/cs5  7 7b  97/proj  docs/teaml  / design.htmll 

26.  Porting  Plan:  A  porting  plan  lists  the  main  tasks  of  the  port  and  some  of  the 
associated  information  for  each  task  (start  date,  end  date,  elapsed  time,  dependencies, 
who  is  assigned,  etc.).  [IBM; 

http://www.ibm.com/developerworks/db2/zones/porting/planning.html1  In 
programming,  to  “port”  (verb)  is  to  move  an  application  program  from  an  operating 
system  environment  in  which  it  was  developed  to  another  operating  system 
environment  so  it  can  be  run  there.  Porting  implies  some  work,  but  not  nearly  as 
much  as  redeveloping  the  program  in  the  new  environment,  open  standard 
programming  interface  (such  as  those  specified  in  X/Open's  1 170  C  language 
specification  and  Sun  Microsystem’s  Java  programming  language)  minimize  or 
eliminate  the  work  required  to  port  a  program.  [SearchNetworking.com; 
http://searchnetworking.techtarget.com/sDefinition/0„sid7  gci2 12807, OO.htmll 

27.  Waveform  Port  Report 

28.  Waveform  Description  Document 

29.  Security  Engine:  A  security  engine  is  a  software  resource  that  enforces  security 
policies  designed  to  help  ensure  that  a  vulnerability  of  an  application  or  operating 
system  cannot  be  exploited.  [Free  Patents  Online; 
http://www.freepatentsonline.coin/20060021002.html1 

30.  Software  Estimation  File:  The  software  estimate  file  contains  the  estimation  of  the 
software  size,  cost,  schedule,  and  critical  computer  resources  critical  to  the  effective 
planning  and  tracking  of  a  software-intensive  project. 
[http://sepo.spawar.navy.mil/SW  Estimation  Process  Expert  Mode.docl 

3 1 .  Software  Security  Report 

32.  Software  Metrics  Report:  The  software  metrics  report  presents  guidelines  for 
establishing  a  software  measurement  process  as  part  of  an  organization’s  overall 
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software  process.  [IT  Metrics  &  Productivity  Institute; 
http  ://www.  itmpi.  org/default.  aspx?pageid=23  5 1 

33.  Interface  Control  Document:  An  interface  control  document  describes  the 
relationship  between  two  components  of  a  system  in  terms  of  data  items  and 
messages  passed,  protocols  observed  and  timing  and  sequencing  of  events.  [Chamber 
of  Commerce;  http://www.chambers.com.au/glossary/icd.html 

34.  Software  Maintenance  Plan  (or  Software  Configuration  Management  Plan):  A 
software  configuration  management  plan  enables  the  controlled  and  repeatable 
management  of  information  technology  components  as  they  evolve  in  all  stages  of 
development  and  maintenance.  Enables  the  controlled  and  repeatable  management  of 
information  technology  components  as  they  evolve  in  all  stages  of  development  and 
maintenance.  [State  of  Michigan] 

35.  Product  Reuse  Demonstration  Inventory  List:  A  detailed  list  of  all  code  files  in  the 
product  baseline,  including  all  third-party  software  (operating  systems,  middleware, 
applications,  and  device  drivers)  not  delivered  within  the  terms  of  the  contract  but 
used  in  the  system  to  form  the  working  product. 

36.  Product  Reuse  Demonstration  Inspection  Report:  A  detailed  list  of  all  company 
markings  found  in  the  source  code  to  ensure  the  Government  has  GPR  to  use  the 
software  delivered  in  the  contract. 

37.  Product  Reuse  Demonstration  Build  Procedure  Development  Report:  A  report 
containing  a  build  procedure  in  sufficient  detail  to  allow  a  third  party  to  recreate  the 
operational  system  on  a  compatible  processing  platform.  It  shall  address  the  results 
of  the  code  inventory  and  inspection  to  account  for  software  that  is  not  deliverable 
due  to  proprietary  rights  limitations  such  that  the  user  can  complete  the  installation 
process. 

38.  Product  Reuse  Demonstration  Report:  A  report  detailing  the  results  of  the  formal 
demonstration  of  the  build  process  using  the  product  baseline  software  and  approved 
procedures  showing  the  software  can  be  successfully  ported  to  other  third-party 
compatible  open  architecture  processing  systems. 
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Appendix  2:  NOA  CHECKLIST  (short) 

The  items  below  are  intended  to  be  a  quick  check  on  a  system’s  programmatics  that, 
when  properly  applied,  will  yield  the  benefits  of  an  open  system. 

□  For  components  which  are  expected  to  evolve  to  meet  new  or  unforeseen 
performance  requirements,  does  the  Government  have  at  least  Government 
Purpose  Rights  (GPR)  in  any  software  or  documentation  being  developed  or  used 
to  build  the  system? 

□  Are  proprietary  components  well-defined,  limited  in  scope,  and  designed  so  that 
others  are  not  precluded  from  interfacing  with  the  component  or  other  parts  of  the 
system  or  from  developing  and  providing  components  with  comparable  or 
improved  performance  and  form,  fit  and  function? 

□  Are  your  program’s  design  artifacts  disclosed  “early  and  often”  and  freely 
available  for  reuse  by  another  program  or  third  parties? 

□  Is  design  disclosure  enabled  by  keeping  data,  code  and  design  artifacts  in  a 
repository  either  maintained  by  or  overseen  by  the  Government,  such  as  the 
Surface  Domain’s  SHARE  Repository  or  the  C4I  Domain’s  NESI  Collaboration 
site;  providing  the  artifacts  electronically  upon  requests  made  via  the 
Government;  allowing  requesting  parties  to  obtain  them  directly  from  the  source 
firm  through  a  process  involving  review  and  approval  from  the  Government;  or 
requiring  that  contractors  allow  the  program  to  have  continuous,  real-time  access 
to  the  development  environment  with  access  to  artifacts? 

□  Does  the  program  use  widely-accepted  and  supported  standards  to  define  interface 
definitions  or  key  interfaces  that  are  published  and  maintained  by  recognized 
organizations? 

□  Does  your  program  encourage  continuous  competition  for  components,  modules, 
and  tasks?  Is  it  easy  for  your  follow  on  contract  to  go  to  anyone  other  than  the 
incumbent? 

□  Does  your  program  utilize  commodity  products  (i.e.  COTS  products  with  a  large 
user  base)?  Can  the  decision  leading  to  the  selection  of  specific  COTS  products 
be  supported  (e.g.,  with  test  results,  architectural  suitability,  “best  value” 
assessments,  etc.)? 

□  Does  your  program  use  modules  or  components  that  are  also  being  used  by  other 
programs  with  different  product  vendors? 

□  Does  the  Program  plan  and  directive  documentation  specify  that  anything  the 
government  paid  to  develop  is  available  for  delivery  to  the  Government  with  all 
of  the  developmental  artifacts  and  unlimited  usage  rights? 

□  Does  your  program  use  an  integrated  team  approach  to  identify  how  changes 
affect  the  system? 

□  Is  the  infrastructure  of  your  system  open?  (Operating  System,  Databases, 
Communications,  Interfaces,  Tools) 

□  Does  porting  to  a  new  hardware  platform  require  minimal  time  and  resources? 
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Appendix  3:  NOA  CHECKLIST  (long) 


OPNAV  has  established  five  principles  of  Naval  Open  Architecture  (NOA)  that  form  the 
basis  for  system  design  and  program  management  of  weapons  systems.  The  items  below 
are  intended  to  be  a  quick  check  on  a  system’s  programmatics  that,  when  properly 
applied,  will  yield  the  benefits  of  an  open  system. 

Modular  Design  and  Design  Disclosure 

□  Has  the  system  design  separated  hardware  from  operating  system  from 
middleware  from  applications? 

□  Are  the  system’s  applications  functionally  segregated  to  provide  separability  and 
the  ability  to  function  as  independent  entities? 

□  Can  the  computing  plant  be  upgraded  without  the  necessity  to  change  operating 
system,  middleware  or  applications? 

□  Are  the  functional  components  of  the  system  well  defined  with  clearly  specified 
functions  and  interfaces? 

□  Are  the  system/subsystem/component/application  specifications  and  design  data 
available  to  a  broad  cross  section  of  potential  providers? 

□  Is  design  disclosure  accomplished  on  a  frequent  basis  throughout  the  development 
process? 

□  Is  design  disclosure  enabled  by  keeping  data,  code  and  design  artifacts  in  a 
repository  either  maintained  by  or  overseen  by  the  Government  such  as  the 
Surface  Domain’s  SHARE  Repository  or  the  C4I  Domain’s  NESI  Collaboration 
Site;  providing  the  artifacts  electronically  upon  requests  made  via  the 
Government;  allowing  requesting  parties  to  obtain  them  directly  from  the  source 
firm  through  a  process  involving  review  and  approval  from  the  Government;  or 
requiring  that  contractors  allow  the  program  to  have  continuous,  real-time  access 
to  the  development  environment  with  access  to  artifacts? 

□  Does  the  Program  plan  and  directive  documentation  specify  that  anything  the 
government  paid  to  develop  is  available  for  delivery  to  the  Government  with  all 
of  the  developmental  artifacts  and  unlimited  usage  rights? 

Reusable  Application  Software 

Reuse  practices  by  the  program; 

□  Has  the  program  investigated  potential  reuse  components  from  other  programs? 

□  Has  the  contract/RFP  required  the  prospective  integrator  to  conduct  market 
research  to  identify  potential  reuse  candidates  from  a  broad  spectrum  of 
providers? 

□  Does  the  program  participate  in  Domain/Community  of  Interest  asset  reuse 
repository/library  capabilities? 

□  Can  Programs  ensure  that  potential  Offerors  who  do  not  have  access  to  reuse 
repositories/libraries  because  they  lack  a  current  contractual  vehicle  are  informed 
of  the  contents  of  the  repositories  and  allowed  access  to  artifacts  as  appropriate? 
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Creating  assets  suitable  for  potential  reuse; 

□  Are  applications  created  with  well-defined  and  documented  interfaces? 

□  Have  widely-accepted  standards  been  used  in  application  design? 

□  Are  the  application  functional  requirements  clearly  defined  and  well  documented? 

□  Have  the  test  cases  for  each  application  been  documented  and  made  available? 

□  Is  the  development  environment  for  each  application  an  industry  standard,  openly 
available  product? 

□  Have  the  appropriate  data  rights  been  obtained  with  each  application  (normally 
Government  Purpose  Rights)? 

□  If  a  product  contains  proprietary  elements,  are  the  license  requirements  for  use 
clearly  documented,  and  those  proprietary  elements  segregated  with  well-defined 
interfaces  such  that  modification  of  another  component  will  not  require 
modification  of  the  proprietary  product? 

□  Does  the  RFP/Contract  require  that  the  vendor  provide  deliverables  that  are 
structured  to  provide  for  discovery  and  potential  reuse  of  the  asset? 

□  Have  the  asset  packages  (i.e.,  the  deliverable)  been  reviewed  prior  to  Government 
acceptance  to  ensure  that  they  contain  only  the  agreed  upon  license  and  data 
rights  markings? 

Interoperable  joint  warfighting  applications  and  secure  information  exchange 

□  Have  the  functions  of  the  application  been  well  defined  to  facilitate  commonality 
with  other  service  programs? 

□  Has  the  application/system  been  designed  to  conform  to  a  community  of 
interest/joint  warfighting  data/information  model? 

□  Does  the  application/system  comply  with  current  infonnation  assurance  standards 
and  requirements? 

□  Is  the  application/system  designed  to  function  in  a  net-centric  environment 
according  to  well-defined,  net-ready  Key  Performance  Parameters  (KPPs)? 

□  Has  the  system  design  considered  and  does  it  comply  with  a  higher-level 
architecture  to  facilitate  interoperability? 

□  Is  there  continual,  data-driven  assessment  of  deployed  operational  perfonnance 
incorporating  end-user  feedback  and  explicit  data  gathered  from  real  world 
operations? 

Life  Cycle  Affordability 

□  Has  the  system/program  leveraged  common  development  and  maintenance  of 
applications  with  another  system/program  to  reduce  life  cycle  software 
maintenance  costs? 

□  Has  the  program  executed  Performance  Based  Logistics  (PBL)  agreements  for  life 
cycle  support  that  leverage  the  advantages  of  COTS  hardware? 

□  Do  PBL  agreements  employ  distance  support  techniques  to  reduce  down  time  and 
reduce  cost? 
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□  Is  operator  and  maintenance  training  optimized  to  support  shortened  cycle  times 
and  leverage  commercial  training? 

□  Are  training  systems  designed  to  leverage  the  COTS  nature  of  open  system 
architecture  systems  to  provide  better  fidelity  to  operational  systems  and  reduce 
cost? 

□  Has  the  program  built  in  incentive  structures  to  reward  reduction  in  total 
ownership  cost  over  the  life  cycle? 

□  Has  the  system  design  reduced  life  cycle  cost  by  leveraging  modularity  to  reduce 
the  effort  and  cycle  time  of  system  modernization? 

□  Has  the  program  made  use  of  commodity  COTS  computing  and  networking 
hardware  to  reduce  procurement  and  maintenance  cost?  Can  the  decision  leading 
to  the  selection  of  specific  COTS  products  be  supported  (e.g.,  with  test  results, 
architectural  suitability,  “best  value”  assessments,  etc.)? 

□  Has  system  modularity  been  leveraged  to  provide  a  hardware  modernization  and 
obsolescence  mitigation  path? 

□  Have  proprietary  products  been  avoided  to  prevent  vendor  lock-in  and  sole  source 
environments? 

Encouraging  Competition  and  Collaboration 

□  Has  the  acquisition  plan  separated  functions  (e.g.,  architect,  integrator,  application 
provider)  to  permit  separate  contracts  for  components  of  the  system? 

□  Has  a  transparent  peer  group  process  been  established  to  provide  for  independent 
evaluation  of  alternative  components  and  selection  of  best  of  breed  components 
for  the  system? 

□  Has  a  collaborative  environment  been  established  to  promote  cooperation  and 
collaboration  among  government  and  industry  partners  in  the  system 
development? 

□  Are  logical  points  in  the  development  cycle  established  at  which  competitive 
processes  can  be  leveraged  to  expand  the  vendor  base  where  advantageous  to  the 
Government? 

□  Can  a  different  vendor  be  chosen  to  provide  any  component  of  the  system  if 
advantageous  to  the  Government? 

□  Have  incentive  structures  been  built  into  the  program  plan  and  contracts  to  reward 
cooperation  and  collaboration  among  the  architect,  integrator,  and  component 
providers? 

□  Has  the  program  leveraged  the  Science  and  Technology  (S&T)  program  to 
identity  innovative  concepts  and  new  participants? 

□  Is  there  a  SBIR  and  technology  transition  plan  in  place  to  encourage  participation 
by  qualified  small  businesses? 

□  Has  the  program  sought  opportunities  for  joint  development  or  component  reuse 
with  other  Naval  and  Joint  programs? 

□  Is  the  end  user  included  in  the  system  design  and  upgrade  process  as  well  as  the 
training  definition? 
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Appendix  4:  RECOMMENDED  DATA  LANGUAGE  FOR  CODE 

HEADERS 


Deliverable  artifacts  should  include  embedded  data  or  language  in  code  headers  or  in 
other  locations  that  provides  key  infonnation  for  those  seeking  to  use  these  items  in  the 
future.  The  following  are  suggestions  that  can  be  used  as  appropriate  for  artifacts 
delivered  under  Unlimited,  GPR,  and  Specially  Negotiated  License  Rights. 

Recommended  Language  Regarding  Restrictive  Rights 

The  Government  must  be  vigilant  in  identifying  and  challenging  any  restrictive 
markings  on  deliverables  that  are  inconsistent  with  the  rights  the  Government  has 
acquired  under  the  contract.  For  example,  if  the  Government  has  contracted  for  GPR  in  a 
particular  deliverable,  the  contractor  shall  not  mark  that  deliverable  with  any  legend  that 
would  limit  or  contradict  that  GPR  license. 

To  protect  against  this  occurrence,  if  an  individual  supporting  the  [specific] 
program  identifies  any  restrictive  markings  on  a  deliverable,  that  individual  shall 
immediately  notify  the  cognizant  Program  Manager  and  Contracting  Officer  to  ensure 
that  any  such  restrictive  markings  are  consistent  with  the  terms  of  the  contract.  If  those 
markings  are  not  consistent  with  the  tenns  of  the  contract,  the  Government  shall  not 
accept  the  deliverables,  the  Program  Manager  shall  promptly  notify  the  [PEO],  and  the 
Contracting  Officer  shall  promptly  follow  the  procedures  in  DFARS  252.227-7013  and 
DFARS  252.227-7014  for  handling  nonconforming  markings  and  the  procedures  in 
DFARS  252.227-7019  and  DFARS  252.227-7037  for  handling  unjustified  markings. 
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Unlimited 


iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii 

III  SECURITY  CLASSIFICATION:  UNCLASSIFIED 

//////////////////////////////////////////////////////////////////////////////// 

Copyright  (C)  (Date  &  Company) 

Notwithstanding  any  copyright  notice,  U.S.  Government  rights  in  this  work  are  defined  by  DFARS 
252.227-7013  or  DFARS  252.227-7014  as  detailed  below.  Use  of  this  work  other  than  as 
specifically  authorized  by  the  U.S.  Government  may  violate  any  copyrights  that  exist  in  this  work. 

Ill  UNLIMITED  RIGHTS 

III  DFARS  Clause  reference:  252.227-7013  (a)(15)  and  252.227-7014  (a)(15) 

III  Unlimited  Rights.  The  Government  has  the  right  to  use,  modify,  reproduce,  perform, 

III  display,  release  or  disclose  this  (technical  data  or  computer  software)  in  whole  or  in  part,  in 
III  any  manner,  and  for  any  purpose  whatsoever,  and  to  have  or  authorize  others  to  do  so. 

in 

III  Distribution  Statement  D.  Distribution  authorized  to  the  Department  of  Defense  and 
III  U.S.  DoD  contractors  only  in  support  of  US  DoD  efforts.  Other  requests  shall  be 
III  referred  to  [PEO], 

III 

III  Warning:  -  This  document  contains  data  whose  export  is  restricted  by  the  Arms  Export 
III  Control  Act  (Title  22,  U.S.C.,  Sec  2751 ,  et  seq.)  as  amended,  or  the  Export  Administration 
III  Act  (Title  50,  U.S.C.,  App  2401  et  seq.)  as  amended.  Violations  of  these  export  laws 
III  are  subject  to  severe  criminal  and  civil  penalties.  Disseminate  in  accordance  with 
III  provisions  of  DoD  Directive  5230.25. 
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llllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllll 
III  SECURITY  CLASSIFICATION:  UNCLASSIFIED 
//////////////////////////////////////////////////////////////////////////////// 

Copyright  (C)  (Date  &  Company) 

Notwithstanding  any  copyright  notice,  U.S.  Government  rights  in  this  work  are  defined  by  DFARS 
252.227-7013  (f)(2)  and  DFARS  252.227-7014  (f)(2)  as  detailed  below.  Use  of  this  work  other 
than  as  specifically  authorized  by  the  U.S.  Government  may  violate  any  copyrights  that  exist  in 
this  work. 

Ill  GOVERNMENT  PURPOSE  RIGHTS 

///Rights  in  Technical  Data,  computer  software  &  documentation  in  non-commercial  items 
///DFARS  Clause:  252.227-7013  (f)(2)  and  252.227-7014  (f)(2) 

Government  Purpose  Rights.  The  Government's  rights  to  use,  modify,  reproduce,  release, 
perform,  display,  or  disclose  these  technical  data  are  restricted  by  paragraph  (b)(2)  of  the  Rights 
in  Technical  Data-Noncommercial  Items  clause  contained  in  the  below  identified  contract.  No 
restrictions  apply  after  the  expiration  date  shown  below.  Any  reproduction  of  technical  data  or 
portions  thereof  marked  with  this  legend  must  also  reproduce  the  markings. 

Contract  No. 
contractor  Name 
contractor  Address 
Expiration  Data 


III 

III  Distribution  Statement  D.  Distribution  authorized  to  the  Department  of  Defense  and 
III  U.S.  DoD  contractors  only  in  support  of  US  DoD  efforts.  Other  requests  shall  be 
III  referred  to  [PEO], 

III 

III  Warning:  -  This  document  contains  data  whose  export  is  restricted  by  the  Arms  Export 
III  Control  Act  (Title  22,  U.S.C.,  Sec  2751 ,  et  seq.)  as  amended,  or  the  Export  Administration 
III  Act  (Title  50,  U.S.C.,  App  2401  et  seq.)  as  amended.  Violations  of  these  export  laws 
III  are  subject  to  severe  criminal  and  civil  penalties.  Disseminate  in  accordance  with 
III  provisions  of  DoD  Directive  5230.25. 
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III  SECURITY  CLASSIFICATION:  UNCLASSIFIED 
//////////////////////////////////////////////////////////////////////////////// 

Copyright  (C)  (Date  &  Company) 

Notwithstanding  any  copyright  notice,  U.S.  Government  rights  in  this  work  are  defined  by  DFARS 
252.227-7013  (f)(2)  and  DFARS  252.227-7014  (f)(2)  as  detailed  below.  Use  of  this  work  other 
than  as  specifically  authorized  by  the  U.S.  Government  may  violate  any  copyrights  that  exist  in 
this  work. 

Ill  Specially  Negotiated  License  Rights  (Special  GPR) 

///Rights  in  Technical  Data,  computer  software  &  documentation  in  non-commercial  items 
///DFARS  Clause:  252.227-7013  (f)(2)  and  252.227-7014  (f)(2) 

The  Government's  rights  to  use,  modify,  reproduce,  release,  perform,  display,  or  disclose  these 
technical  data  and  computer  software  are  restricted  by  the  specially  negotiated  Government 
Purpose  Rights  license  contained  in  the  below  identified  agreement  at  clause  H-  .  Any 
reproduction  of  technical  data  or  portions  thereof  marked  with  this  legend  must  also  reproduce 
the  markings. 

Contract  No. 
contractor  Name: 
contractor  Address: 

Expiration  Data: 

III 

III  Distribution  Statement  D.  Distribution  authorized  to  the  Department  of  Defense  and 
III  U.S.  DoD  contractors  only  in  support  of  US  DoD  efforts.  Other  requests  shall  be 
/// referred  to  JPEOJTRS. 

Ill 

III  Warning:  -  This  document  contains  data  whose  export  is  restricted  by  the  Arms  Export 
III  Control  Act  (Title  22,  U.S.C.,  Sec  2751 ,  et  seq.)  as  amended,  or  the  Export 
III  Administration  Act  (Title  50,  U.S.C.,  App  2401  et  seq.)  as  amended.  Violations  of 
III  these  export  laws  are  subject  to  severe  criminal  and  civil  penalties.  Disseminate  in 
III  accordance  with  provisions  of  DoD  Directive  5230.25. 
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Appendix  5:  OPEN  SOURCE  SOFTWARE 


Open  Source  Software  (OSS)  is  a  valuable  resource  for  the  development  of  modern 
National  Security  Systems  (NSS).  Many  OSS  products  are  robust  and  can  be  integrated 
with  low  technical  risk  and  provide  a  high  degree  of  design  disclosure.  However,  there 
are  certain  programmatic  issues  or  risks  that  must  be  evaluated  when  selecting  OSS 
products.  The  terms  “open  source”  and  “open  architecture”  are  often  confused  and  at 
times  even  used  interchangeably.  However,  these  terms  are  distinct.  “Naval  Open 
Architecture”  (NOA)  refers  to  business  and  technical  principles  the  Navy  and  Marine 
Corps  are  applying  to  modernize  its  Fleet  and  systems,  reduce  costs,  decrease  time  to 
field,  and  facilitate  rapid  technology  insertion  (and  is  defined  in  the  Glossary).  “Open 
architecture”  is  a  type  of  architecture  (or  design)  whose  specifications  are  made  public  by 
its  designers  which  allows  users  to  make  modifications  to  various  components.  It  should 
be  noted  that  “openness”  can  be  thought  of  in  degrees,  based  on  the  level  and  scope  of  the 
information  provided  and  its  availability  to  third  parties.  OSJTF  defines  “open  system 
architecture”  as  a  system  that  employs  modular  design,  uses  widely  supported  and 
consensus  based  standards  for  its  key  interfaces,  and  has  been  subjected  to  successful 
validation  and  verification  tests  to  ensure  the  openness  of  its  key  interfaces. 

Open  source  software  is  a  good  resource  for  assisting  in  the  implementation  of  the 
technical  aspects  of  open  architecture  but  its  use  is  not  sufficient  for  a  system  to  be 
“open.”  According  to  the  Open  Source  Initiative,  “open  source  doesn’t  just  mean  access 
to  the  source  code.”  The  distribution  terms  of  the  open-source  software  must  also  comply 
with  10  criteria,  several  of  which  include:  (1)  free  distribution;  (2)  include  the  source 
code;  (3)  allow  modifications  and  derived  works;  and  (4)  distribution  of  the  license.17 
The  following  is  recommended  guidance  for  Navy  and  Marine  Corps  Program  Managers 
who  choose  to  use  open  source  software  in  their  systems. 

General  Information: 

DoD  Memorandum  Clarifying  Guidance  Regarding  Open  Source  Software  (OSS) 

On  October  16,  2009,  acting  Assistant  Secretary  of  Defense  (Networks  &  Information 
Integration)  /  DoD  Chief  Information  Officer  (CIO)  David  M.  Wennergren  promulgated  a 
Memorandum  for  Secretaries  of  the  Military  Departments  on  Clarifying  Guidance 
Regarding  Open  Source  Software  (OSS).  In  the  memo,  Wennergren  noted  that  “there 
have  been  misconceptions  and  misinterpretations  of  the  existing  laws,  policies  and 
regulations  that  deal  with  software  and  apply  to  OSS,  that  have  hampered  effective  DoD 
use  and  development  of  OSS.” 

The  DoD  guidance  acknowledges  that  in  “almost  all  cases,  OSS  meets  the  definition  of 
‘commercial  computer  software’.”  It  also  details  some  “positive  aspects”  of  OSS  to  be 
considered  when  conducting  market  research  into  commercial  computer  software: 


17  A  more  complete  definition  of  open  source,  including  all  10  open  source  criteria,  is 
available  from  the  Open  Source  Initiative’s  website  at  http://www.opensource.org. 
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•  Continuous  and  broad  peer-review  supports  software  reliability  efforts; 

•  Unrestricted  ability  to  modify  source  code  enables  rapid  responses  to  changing 
situations; 

•  Reduced  reliance  on  a  particular  software  developer  or  vendor; 

•  Lack  of  restrictions  on  who  can  use  the  software  and  in  what  fields  of  endeavor  it 
can  be  used,  thus  enabling  a  net-centric  licensing  model; 

•  A  cost  advantage  due  to  its  typical  lack  of  a  per-seat  licensing  cost; 

•  Reduced  total  ownership  cost  due  to  shared  maintenance  responsibility;  and 

•  Suitability  for  rapid  prototyping  and  experimentation  due  to  the  ability  to  “test 
drive”  the  software  with  minimal  costs  and  delays. 

Additionally,  the  guidance  highlights  the  common  “misconception  that  the  Government 
is  always  obligated  to  distribute  the  source  code  of  any  modified  OSS  to  the  public,  and 
therefore  that  OSS  should  not  be  integrated  or  modified  for  use  in  classified  or  other 
sensitive  DoD  systems.  In  contrast,  many  open  source  licenses  permit  the  user  to  modify 
OSS  for  internal  use  without  being  obligated  to  distribute  source  code  to  the  public.” 

More  information  on  the  DoD’s  policies  with  respect  to  OSS  is  available  at 
http://www.defenselink.mil/cio-nii/sites/oss/index.shtml.  The  October  16  memo  is 
available  at  http://www.defenselink.mil/cio-nii/sites/oss/20090SS.pdf. 

As  the  DoD  guidance  states,  open  source  software  is  generally  regarded  as  commercial 
computer  software  for  which  the  source  code  is  publicly  available  to  all  users  under 
specific  licensing  terms  and  conditions  that  provide  a  user  the  right  to  use,  modify,  and 
redistribute  the  modified  open  source  software  to  the  public.  Some  open  source  software 
licenses  require  that,  if  further  distributed,  the  modified  open  source  software  be 
distributed  under  the  terms  and  conditions  of  the  original  license. 

To  accept  open  source  software,  the  Government  must  be  prepared  to  accept  delivery  of 
open  source  software  under  the  terms  of  the  open  source  software  license,  and  with  the 
knowledge  that  Government  will  not  be  able  to  negotiate  the  open  source  software 
license  terms.  At  the  same  time,  the  Government  must  also  comply  with  the  licensing 
and  operational  security  requirements  of  non-open  source  software.  Government  cannot 
modify  open  source  software  by  merging  open  source  software  with  computer  software 
that  is  classified  or  otherwise  not  releasable  to  the  public  because  of  licensing  or  data 
rights  restrictions. 

Thus,  to  accept  delivery  of  open  source  software  while  complying  with  all  computer 
software  licensing  requirements,  the  Government  must  have  a  very  good  understanding 
of: 

1 .  What  the  open  source  software  is  and  the  licensing  constraints  for  the  open  source 
software; 

2.  How  the  open  source  software  will  be  used  within  the  system  being  procured; 

3.  Whether  it  is  likely  the  open  source  software  will  need  to  be  modified  and/or 
distributed  over  the  lifecycle  of  the  system;  and 
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4.  The  impacts  on  non-open  source  computer  software,  both  commercial  and  non¬ 
commercial,  if  distribution  under  the  open  source  software  license  is  required  when  the 
open  source  software  is  modified. 

Issues  to  Consider  When  Using  Open  Source  Software 

Since  open  source  software  is  really  a  particular  type  of  commercial  computer  software, 
open  source  software  is  almost  always  treated  as  commercial  computer  software  under 
the  Defense  Federal  Acquisition  Regulations  Supplement  (DFARS).  As  such,  the  same 
DFARS  policies  that  apply  to  procurement  of  commercial  computer  software  would  also 
apply  to  open  source  software.  That  is,  the  Government  shall  have  only  the  rights 
specified  in  the  license  under  which  the  commercial  computer  software  was  obtained.  If 
the  Government  has  a  need  for  rights  not  normally  conveyed  to  the  public,  then  the 
Government  must  negotiate  with  the  commercial  computer  software  vendor.  See  DFARS 
227.7202-3,  “Rights  in  Commercial  Computer  Software  or  Commercial  Computer 
Software  Documentation.”  But  for  open  source  software,  this  presents  special  problems 
as  detailed  below. 

a)  Inability  to  Negotiate 

The  owner(s)  of  the  intellectual  property  rights  in  the  open  source  software  generally  are 
not  available  for  negotiating  lesser  or  greater  rights  than  those  rights  provided  by  the 
license  that  governs  the  open  source  software.  Accordingly,  the  Government  must  accept 
open  source  software  under  the  tenns  and  conditions  dictated  by  the  open  source  software 
license  with  the  knowledge  that  the  Government  will  not  be  able  to  negotiate  the  open 
source  software  license  terms. 

b)  “Viral”  Licenses 

Open  source  software  delivered  or  used  to  perfonn  work  under  government  contracts 
may  be  unmodified  or  modified.  If  modified,  “viral’  open  source  software  licenses 
require  that  the  modified  open  source  software,  if  further  distributed,  be  distributed  under 
the  terms  and  conditions  of  the  license  covering  the  original  unmodified  open  source 
software.  Accordingly,  the  Government  cannot  modify  open  source  software  that  is 
governed  by  viral  licenses  by  merging  open  source  software  with  computer  software  that 
is  classified  or  otherwise  not  releasable  to  the  public  due  to  proprietary  restrictions  (for 
commercial  computer  software)  or  data  rights  restrictions  (for  non-commercial  computer 
software).  This  is  because  the  Government  may  want  to  distribute  the 
classified/restricted  software  on  its  own  tenns,  or  not  at  all.  If  there  is  a  need  to  further 
distribute  the  open  source  software  that  is  accepted  for  delivery,  the  Government  must  be 
aware  of  whether  the  open  source  software  has  a  viral  license  and  whether  the  open 
source  software  has  been  modified,  and  how.  In  some  cases,  a  well-defined  Application 
Programming  Interface  (API)  may  be  provided  to  serve  as  a  buffer  between  the  open 
source  software  and  the  other  non-open  source  software,  which  Government  desires  to 
distribute  under  its  own  terms,  or  not  at  all.  With  respect  to  Naval  Open  Architecture,  the 
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Government  prefers  to  distribute  software  under  the  Software-Hardware  Asset 
Repository  Enterprise  (SHARE)  license. 

(c)  Authorization  and  Consent.  Open  source  software  may  be  covered  by  a 
patent  of  the  United  States,  or  by  copyright  under  the  Copyright  Act  (Title  17,  U.S. 
Code).  When  the  Government  “authorizes  and  consents”  to  patent  or  copyright 
infringement  under  28  U.S.C.  §1498,  the  Government  may  be  sued  for  money  damages 
for  the  infringement  but  not  enjoined  from  using  the  open  source  software.  However, 
where  the  Government  does  not  “authorize  or  consent,”  the  contractor  may  be  sued  for 
money  damages  and  may  be  enjoined  from  further  use  of  the  open  source  software. 

(i)  As  a  general  rule,  the  Government  should  not  insert  an  authorization 
and  consent  clause  in  contracts  involving  open  source  software  deliverables,  or 
where  open  source  software  is  used  to  develop  a  non-commercial  computer 
software  deliverable.  However,  the  Government  may  give  authorization  and 
consent  to  ensure  that  work  under  a  Government  contract  is  not  enjoined  in 
certain  cases,  such  as  when  the  quality  of  the  open  source  software  justifies 
acceptance  despite  the  licensing  constraints,  where  there  are  no  acceptable 
substitutes,  where  time  constraints  for  delivery  do  not  allow  for  substitutes,  etc. 

(ii)  As  discussed  above,  open  source  software  is  automatically  licensed  to 
a  user  on  nonnegotiable  terms.  Accordingly,  a  contractor  may  accept  the  open 
source  software  license  subjecting  them  to  possible  infringement  liability;  license 
or  develop  alternative  software;  obtain  an  authorization  and  consent  clause  to  shift 
the  infringement  liability  to  the  Government;  or  rely  on  the  doctrine  of  implied 
authorization  and  consent.  If  it  is  appropriate  for  the  Government  to  authorize 
and  consent  to  patent  and  copyright  infringement  for  open  source  software,  the 
Contract  Officer  may  grant  the  authorization 

Program  Managers  and  Data  Managers  Actions 

Program  Managers  and  data  managers  should  know  and  understand  what  open  source 
software  is  proposed  for  delivery  or  perfonnance  of  work  under  the  contract,  what 
licenses  govern  the  open  source  software,  where  the  open  source  software  is  to  be  used 
and  whether  the  open  source  software  has  been  or  will  be  modified.  With  this  knowledge 
and  understanding,  Program  Managers  and  data  managers  should  evaluate  use  of  the 
open  source  software  in  light  of  the  issues  discussed  above.  Some  open  source  software 
licenses  are  fairly  innocuous  (i.e.  attribution,  promise  not-to-sue,  etc.),  but  others  are  not. 

If  the  license  is  “viral,”  the  program  has  to  understand  what  it  will  be  using  the  open 
source  software  for  and  whether  it  will  be  used  in  conjunction  with  assets  obtained  from 
the  SHARE  library  or  assets  contributed  to  the  SHARE  library  (see  the  SHARE  license). 

(1)  To  record  the  due  diligence  described  above,  and  to  facilitate  acceptance  of 
open  source  software  delivery,  use  a  list  which  becomes  an  Attachment  to  Section  J  of 
the  Contract.  A  suggested  format  for  the  Attachment  is  as  follows: 
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Identification  of  Open  Source  Software  Use  and  Modifications 


Open  Source 
Software  Title 
and  Version  # 

License  and 
Version  # 

Name  of 

contractor 

Asserting 

Restrictions 

Was  Open  Source 
Software  modified 
by  contractor? 

If  Modified,  was  Open 
Source  Software 
modified  by 
incorporation  into  a 
third  party’s  software? 

Use  of  OSS  in  Performing  Under  a  Contract  But  Not  for  Delivery 

In  cases  where  the  contractor  proposes  to  use  open  source  software  while  performing 
under  a  contract,  but  not  to  deliver  open  source  software,  program  managers  and  data 
managers  should  take  care  that  such  use  does  not  create  Government  obligations  under 
the  open  source  software  licensing  scheme.  The  following  language  is  suggested  for 
incorporation  into  procurement  actions. 

“Open  source  software. . .  is  often  licensed  under  terms  that  require  the  user  to  make  the 
user’s  modifications  to  the  open  source  software  or  any  software  that  the  user  ’combines’ 
with  the  open  source  software  freely  available  in  source  code  form.”  If  the  contractor 
uses  open  source  software  in  the  performance  of  a  Government  contract,  it  must  ensure 
that  the  use  thereof  does  not;  (i)  create,  or  purport  to  create,  any  Government  distribution 
obligations  with  respect  to  the  computer  software  deliverables;  or  (ii)  grant,  or  purport  to 
grant,  to  any  third  party  any  rights  to  or  immunities  under  Government  intellectual 
property  or  Government  data  rights  to  the  Government  computer  software  deliverables. 

For  example,  the  contractor  may  not  develop  a  computer  software  deliverable  using  a 
open  source  program  (including  without  limitation  libraries)  and  non-commercial 
computer  software  program  where  such  use  results  in  a  program  file(s)  that  contains  code 
from  both  the  non-commercial  computer  software  and  open  source  software  if  the  open 
source  software  is  licensed  under  a  license  that  requires  any  ‘modifications’  be  made 
freely  available.  Additionally,  the  contractor  may  not  combine  any  non-commercial 
computer  software  deliverable  with  open  source  software  licensed  under  the  General 
Public  License  (GPL)  or  the  Lesser  General  Public  License  (LGPL)  in  any  manner  where 
such  use  would  cause,  or  could  be  interpreted  or  asserted  to  cause,  the  non-commercial 
computer  software  deliverable  or  any  modifications  thereto  to  become  subject  to  the 
tenns  of  the  GPL  or  LGPL.” 
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Appendix  6:  GLOSSARY  OF  TERMS 


Please  Note:  The  definitions  of  the  following  tenns  are  included  as  guidance  for  the 
Preparer  and  were  compiled  from  the  sources  indicated  in  brackets  and  italics  following 
each  definition  and  were  provided  in  this  appendix  for  the  user’s  convenience.  It  is  not 
intended  to  be  authoritative  or  comprehensive.  For  the  definitions  of  additional  terms  or 
clarification  of  these  definitions,  please  refer  to  the  Defense  Federal  Acquisition 
Regulation  Supplement  (DFARS)  and  other  source  documents. 

“Activity”  is  set  of  actions  which,  taken  as  a  whole,  transfonn  inputs  into  outputs. 
[IEEE/EIA  Std.  12207/1997] 

“APP233/ISO  10303”  -  APP233  an  “Application  Protocol”  for  Systems  Engineering 
that  is  based  on  the  ISO  10303  Standard.  AP233  is  specific  to  Systems  Engineering,  but 
its  purpose,  like  all  of  the  10303  standards,  is  to  allow  data  exchange  of  SE  models 
between  tools  —  it  does  not  limit  what  “language”  the  tools  use  to  represent  a  system. 
Neither  is  it  meant  to  be  a  human-readable  language,  so  using  it  directly  for  "tool 
neutrality"  is  not  likely  to  work.  ISO  10303  “is  an  International  Standard  for  the 
computer-interpretable  representation  and  exchange  of  industrial  product  data.  The 
objective  is  to  provide  a  mechanism  that  is  capable  of  describing  product  data  throughout 
the  life  cycle  of  a  product,  independent  from  any  particular  system.  The  nature  of  this 
description  makes  it  suitable  not  only  for  neutral  file  exchange,  but  also  as  a  basis  for 
implementing  and  sharing  product  databases  and  archiving.”  [ Source  is  Wikipedia]. 

“Architecture”  means  the  fundamental  organization  of  a  system  embodied  in  its 
components,  their  relationships  to  each  other,  and  to  the  environment,  and  the  principles 
guiding  its  design  and  evolution.  [Institute  of  Electrical  and  Electronics  Engineers 
(IEEE)  Std  1471-2000] 

“Commercial  component”  means  any  component  that  is  a  commercial  item.  [FAR 
§2. 101(b)] 

“Commercial  item”  means; 

(1)  Any  item,  other  than  real  property,  that  is  of  a  type  customarily  used  by  the  general 
public  or  by  non-governmental  entities  for  purposes  other  than  Governmental  purposes, 
and: 

(i)  Has  been  sold,  leased,  or  licensed  to  the  general  public;  or 

(ii)  Has  been  offered  for  sale,  lease,  or  license  to  the  general  public; 

(2)  Any  item  that  evolved  from  an  item  described  in  paragraph  (1)  of  this  definition 
through  advances  in  technology  or  performance  and  that  is  not  yet  available  in  the 
commercial  marketplace,  but  will  be  available  in  the  commercial  marketplace  in  time  to 
satisfy  the  delivery  requirements  under  a  Government  solicitation; 

(3)  Any  item  that  would  satisfy  a  criterion  expressed  in  paragraphs  (1)  or  (2)  of  this 
definition,  but  for; 
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(i)  Modifications  of  a  type  customarily  available  in  the  commercial  marketplace; 
or 

(ii)  Minor  modifications  of  a  type  not  customarily  available  in  the  commercial 
marketplace  made  to  meet  Federal  Government  requirements.  Minor 
modifications  mean  modifications  that  do  not  significantly  alter  the 
nongovernmental  function  or  essential  physical  characteristics  of  an  item  or 
component,  or  change  the  purpose  of  a  process.  Factors  to  be  considered  in 
determining  whether  a  modification  is  minor  include  the  value  and  size  of  the 
modification  and  the  comparative  value  and  size  of  the  final  product.  Dollar 
values  and  percentages  may  be  used  as  guideposts,  but  are  not  conclusive 
evidence  that  a  modification  is  minor; 

(4)  Any  combination  of  items  meeting  the  requirements  of  paragraphs  (1),  (2),  (3),  or  (5) 
of  this  definition  that  are  of  a  type  customarily  combined  and  sold  in  combination  to  the 
general  public; 

(5)  Installation  services,  maintenance  services,  repair  services,  training  services,  and 
other  services  if: 

(1)  Such  services  are  procured  for  support  of  an  item  referred  to  in  paragraph  (1), 

(2) ,  (3),  or  (4)  of  this  definition,  regardless  of  whether  such  services  are  provided 
by  the  same  source  or  at  the  same  time  as  the  item;  and 

(ii)  The  source  of  such  services  provides  similar  services  contemporaneously  to 
the  general  public  under  terms  and  conditions  similar  to  those  offered  to  the 
Federal  Government; 

(6)  Services  of  a  type  offered  and  sold  competitively  in  substantial  quantities  in  the 
commercial  marketplace  based  on  established  catalog  or  market  prices  for  specific  tasks 
performed  or  specific  outcomes  to  be  achieved  and  under  standard  commercial  tenns  and 
conditions.  This  does  not  include  services  that  are  sold  based  on  hourly  rates  without  an 
established  catalog  or  market  price  for  a  specific  service  performed  or  a  specific  outcome 
to  be  achieved.  For  purposes  of  these  services — 

(i)  “Catalog  price”  means  a  price  included  in  a  catalog,  price  list,  schedule,  or 
other  form  that  is  regularly  maintained  by  the  manufacturer  or  vendor,  is  either 
published  or  otherwise  available  for  inspection  by  customers,  and  states  prices  at 
which  sales  are  currently,  or  were  last,  made  to  a  significant  number  of  buyers 
constituting  the  general  public;  and 

(ii)  “Market  prices”  means  current  prices  that  are  established  in  the  course  of 
ordinary  trade  between  buyers  and  sellers  free  to  bargain  and  that  can  be 
substantiated  through  competition  or  from  sources  independent  of  the  Offerors. 

(7)  Any  item,  combination  of  items,  or  service  referred  to  in  paragraphs  (1)  through  (6)  of 
this  definition,  notwithstanding  the  fact  that  the  item,  combination  of  items,  or  service  is 
transferred  between  or  among  separate  divisions,  subsidiaries,  or  affiliates  of  a 
contractor;  or 

(8)  A  non-developmental  item,  if  the  procuring  agency  determines  the  item  was 
developed  exclusively  at  private  expense  and  sold  in  substantial  quantities,  on  a 
competitive  basis,  to  multiple  State  and  local  governments.  [FAR  Part  2.101(b) ] 

“Commercial  Off-the-Shelf  (COTS)”  or  “commercially  available  off-the-shelf  item” 

means  an  item  that — 
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(A)  is  a  commercial  item  (as  described  in  section  403  (12)(A)  of  this  title); 

(B)  is  sold  in  substantial  quantities  in  the  commercial  marketplace;  and 

(C)  is  offered  to  the  Government,  without  modification,  in  the  same  form  in  which  it  is 
sold  in  the  commercial  marketplace.  [Title  41,  Chapter  7,  Section  431] 

“Component”  is  one  of  the  parts  that  make  up  a  system.  A  component  may  be  hardware 
or  software  and  may  be  subdivided  into  other  components.  [IEEE  Std  610.12-1990 \ 

“Community  of  Interest  (COI)”  means  a  collaborative  group  of  users  that  must 
exchange  information  in  pursuit  of  its  shared  goals,  interests,  missions,  or  business 
processes,  and  therefore  must  have  shared  vocabulary  for  the  information  it  exchanges. 
[DoD  8320-2] 


“Design  Disclosure”  means  making  data  related  to  the  design  of  a  component,  sub¬ 
system  or  system  available  to  qualified  recipients,  with  a  goal  of  establishing  and 
maintaining  a  process  that  will  provide  “early  and  often”  design  disclosure  directly  to  the 
Government  or  to  third-party  contractors  via  Government-established  access.  This  data  is 
sufficient  to  allow  the  third  party  to  develop  and  produce  a  competitive  alternative. 

Design  Disclosure  can  be  enabled  through  a  variety  of  mechanisms  including  keeping 
data,  code  and  design  artifacts  in  a  repository  either  maintained  by  or  overseen  by  the 
Government  such  as  the  Surface  Domain’s  SHARE  Repository;  providing  the  artifacts 
electronically  upon  requests  made  via  the  Government;  or  allowing  requesting  parties  to 
obtain  them  directly  from  the  source  firm  through  a  process  involving  review  and 
approval  from  the  Government.  In  addition,  the  Government  can  require  that  contractors 
allow  the  program  to  have  continuous,  real-time  access  to  the  development  environment 
with  access  to  artifacts.  Each  program  has  the  flexibility  to  establish  the  most  appropriate 
mechanism  for  their  specific  needs;  with  a  goal  of  establishing  a  process  that  is  both  cost- 
effective  and  responsive  to  requests. 

“Domain”  represents  an  administrative  structure  based  on  a  common  sphere  of  activities. 
In  relations  to  NOA,  the  Naval  Enterprise  is  divided  into  six  Domains;  Surface, 
Subsurface,  Air,  C4I,  Space,  and  Marine  Corps.  As  specified  in  the  5  August  2004  ASN 
(RDA)  memorandum,  the  Domain  Leads  are  PEO  IWS  (Ships),  PEO  Subs  (Subsurface), 
PEO  T  (Air),  PEO  C4I  (C4I)  and  PEO  (Space).  PEO  IWS  will  act  in  collaboration  with 
PEO  Ships,  PEO  Carriers,  and  PEO  LMW.  PEO  T  will  collaborate  with  the  other  Air 
PEOs  and  COMNAVAIR. 

“Enterprise  Architecture”  represents  the  enterprise's  key  business,  information, 
application,  and  technology  strategies/trends  and  their  impact  on  business  functions  and 
processes. 

[Virginia  Information  Technologies  Agency] 

“Evolving  Architecture”  are  software  development  architectures  that  adopts  changing 
customer  needs  and  rapidly  developing  technologies.  [Carnegie  Mellon  University] 
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“Government  Purpose  Rights”  (GPR)  means  the  rights  to — 

(i)  Use,  modify,  reproduce,  release,  perfonn,  display,  or  disclose  intellectual 
and  technical  data  within  the  Government  without  restriction;  and 

(ii)  Release  or  disclose  intellectual  and  technical  data  outside  the  Government 
and  authorize  persons  to  whom  release  or  disclosure  has  been  made  to  use, 
modify,  reproduce,  release,  perform,  display,  or  disclose  that  data  for  United 
States  Government  Purposes. 

[DFARS  §252.227-701 3(a)(l  2)] 

“Government  Purpose”  means  any  activity  in  which  the  United  States  Government  is  a 
party,  including  cooperative  agreements  with  international  or  multi-national  defense 
organizations,  or  sales  or  transfers  by  the  United  States  Government  to  foreign 
governments  or  international  organizations.  Government  purposes  include  competitive 
procurement,  but  do  not  include  the  rights  to  use,  modify,  reproduce,  release,  perform, 
display,  or  disclose  IP  and  technical  data  for  commercial  purposes  or  authorize  others  to 
do  so.  [DFARS  §252.227-701 3(a)(ll)] 

Note:  In  order  for  a  software/intellectual  property/technical  data  asset  to  be 
a  viable  Reuse  Candidate,  the  Government  must  have  at  least  Government 
Purpose  Rights  in  the  asset. 

“Information  Assurance”  is  information  operations  that  protect  and  defend  information 
and  information  systems  by  ensuring  their  availability,  integrity,  authentication, 
confidentiality,  and  non-repudiation.  This  includes  providing  for  the  restoration  of 
information  systems  by  incorporating  protection,  detection,  and  reaction  capabilities. 
[CJCSI 3 170.0 IE]  Information  Assurance  compliance  requirements  are  contained  in 
CJCSI  3170.01E  and  PEO-specified  requirements. 

“Integrated  Product  Team”  is  a  group  composed  of  representatives  from  appropriate 
functional  disciplines  working  together  to  build  successful  programs,  identify  and  resolve 
issues,  and  make  sound  and  timely  recommendations  to  facilitate  decision  making.  There 
are  three  types  of  IPTs;  1)  Overarching  IPTs  (OIPTs)  that  focus  on  strategic  guidance, 
program  assessment,  and  issue  resolution;  2)  Working-level  IPTs  (WIPTs)  that  identify 
and  resolve  program  issues,  determine  program  status,  and  seek  opportunities  for 
acquisition  reform;  and,  3)  Program-level  IPTs  (PIPTs)  that  focus  on  program  execution 
and  may  include  representatives  from  both  Government  and  after  contract  award 
industry.  [DA  U  Glossary  of  Defense  Acquisition  Acronyms  and  Terms,  13th  Edition] 

“Integrated  Architecture”  consists  of  multiple  views  or  perspectives  (Operational  View 
(OV),  Systems  View  (SV),  Technical  Standards  View  (TV)  and  All  View  (AV))  that 
facilitate  integration  and  promote  interoperability  across  capabilities  and  among  related 
integrated  architectures.  [DoDAF] 

“Interoperability”  is  the  ability  of  systems,  units,  or  forces  to  provide  data,  information, 
materiel,  and  services  to  and  accept  the  same  from  other  systems,  units,  or  forces,  and  to 
use  the  data,  information,  materiel,  and  services  so  exchanged  to  enable  them  to  operate 
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effectively  together.  [DA  U  Glossary  of  Defense  Acquisition  Acronyms  and  Terms,  13  th 
Edition] 

“Invention”  means  any  invention  or  discovery  which  is  or  may  be  patentable  or 
otherwise  protectable  under  Title  35  of  the  United  States  Code  or  any  novel  variety  of 
plant  that  is  or  may  be  protectable  under  the  Plant  Variety  Protection  Act  (7  U.S.C.  2321, 
et  seq.).  [FAR  Section  52.227-12] 

“Layered”  means  a  system  in  which  components  are  grouped,  i.e.,  layered,  in  a 
hierarchical  arrangement,  such  that  lower  layers  provide  functions  and  services  that 
support  the  functions  and  services  of  higher  layers.  Note:  Systems  of  ever-increasing 
complexity  and  capability  can  be  built  by  adding  or  changing  the  layers  to  improve 
overall  system  capability  while  using  the  components  that  are  still  in  place.  [The  Alliance 
for  Telecommunications  Industry  Solutions  (ATIS)  web  site,  http://www. atis. org.1 

“Lead  Systems  Integrator”  has  no  official  definition  in  the  DoD  5000  series  or 
FAR/DFARS.  The  generally  accepted  meaning  of  systems  integrator  is; 

Systems  Integrator  -  A  prime  contractor,  working  with  other  associates  or 
associate  prime  contractors  on  a  system,  whose  function  is  total  responsibility  for 
integrating  the  products/processes/subsystems/components  of  the  associates  or 
associate  prime  contractors  into  the  total  system.  This  contractor  may  have  been 
awarded  a  separate  contract  for  the  integration  effort  or  it  could  be  part  of  the 
contract  for  its  part  of  the  system  being  acquired.  This  contractor  does  not 
necessarily  have  to  have  a  separate  product/process/  subsystem/component  of  the 
system  to  be  the  systems  integrator.  The  systems  integrator  may  also  be  the 
government.  [Defense  Systems  Management  College] 

The  Office  of  the  Undersecretary  of  Defense  (Acquisition,  Test  and  Logistics)  in 
a  Memorandum  entitled  “Limitations  on  contractors  Acting  as  Lead  Systems 
Integrators”  dated  18  January  2007  provided  the  following  definitions; 

•  “Lead  system  integrator  with  system  responsibility”  means  a  prime 
contractor  for  the  development  or  production  of  a  major  system  if  the 
prime  contractor  is  not  expected  at  the  time  of  award  to  perform  a 
substantial  portion  of  the  work  on  the  system  and  the  major  subsystems. 

•  “Lead  system  integrator  without  system  responsibility”  means  a 
contractor  under  a  contract  for  the  procurement  of  services  whose  primary 
purpose  is  to  perform  acquisition  functions  closely  associated  with 
inherently  governmental  functions  with  regard  to  the  development  or 
production  of  a  major  system. 

“Life  Cycle  Model”  in  the  context  of  the  development,  operation,  and  maintenance  of  a 
software  product,  a  life  cycle  model  is  a  defined  set  of  processes,  activities,  and  tasks, 
and  their  sequencing  and  interrelationships,  spanning  the  life  of  the  system  from  its 
definition  to  the  termination  of  its  use.  [IEEE/EIA  Std.  12207/1997] 

“Limited  Rights”  (LR)  means,  in  part,  the  right  to  use,  modify,  reproduce,  release, 
perform,  display,  or  disclose  IP  and  technical  data,  in  whole  or  in  part,  within  the 
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Government.  The  Government  may  not,  without  permission,  release  or  disclose  the  IP 
and  technical  data  outside  the  Government,  use  the  IP  and  technical  data  for  manufacture, 
or  permit  the  IP  and  technical  data  to  be  used  by  another  party,  except; 

•  When  necessary  for  emergency  repair  and  overhaul; 

•  When  used  for  evaluation  or  informational  purposes  by  foreign  governments; 

•  Subject  to  prohibitions  on  further  reuse; 

•  When  the  contractor  asserting  the  restriction  is  notified  of  such  use. 

[DFARS  §252.227. 7013(a)(13)\ 


“Maintainability”  is  directed  toward  achieving  the  reliability  inherent  in  a  design 
through  servicing  and  maintenance,  and  efficiently  restoring  the  system  to  operation 
should  failures  occur.  [Defense  Acquisition  University] 

“Markings”  refers  to  software  and  other  Intellectual  Property  Rights  (IPRs)  legends, 
distribution  statements,  security  classifications,  and  appropriate  export  control 
statements.  It  is  important  that  Program  Managers  review  the  markings  of  all 
deliverables  prior  to  acceptance  to  ensure  that  the  Government  will  obtain  the  IPRs  it  has 
contracted  for. 

“Method/Technique”  -  The  approach  used  to  accomplish  the  task.  [IEEE/EIA  Std. 
12207/1997] 

“Module”  is  a  discrete,  small-grained  unit  of  functionality,  either  hardware  or  software, 
with  a  well-defined,  open  and  published  interface.  Modules  are  combined  with  other 
modules  to  create  components,  services,  and  packages. 

“Modular  Contracting”  is  a  contracting  approach  under  which  the  need  for  a  system  is 
satisfied  in  successive  acquisitions  of  interoperable  increments.  Each  increment  complies 
with  common  or  commercially  acceptable  standards  applicable  to  information  technology 
(IT)  so  that  the  increments  are  compatible  with  the  other  increments  of  IT  comprising  the 
system.  [Glossary  of  Defense  Acquisition  Acronyms  &  Terms,  13th  Edition,  Nov.  2009 ] 

“Modular  Design”  means  a  design  (organization)  where  functionality  is  partitioned  into 
discrete,  cohesive,  and  self-contained  units  with  well-defined,  open  and  published 
interfaces  that  pennit  substitution  of  such  units  with  similar  components  or  products  from 
alternate  sources  with  minimum  impact  on  existing  units.  [A  Modular  Open  Systems 
Approach  (MOSA)  to  Acquisition  document,  (USD(AT&L))  OSJTF] 

“Modular  Open  Systems  Approach  or  MOSA”  is  the  DoD’s  implementation  of  Open 
Systems.  Within  the  MOSA  context,  programs  should  design  their  system  based  on 
adherence  to  the  following  five  MOSA  principles; 

•  Establish  an  Enabling  Environment. 

•  Employ  Modular  Design. 

•  Designate  Key  Interfaces. 

•  Use  Open  Standards. 

•  Certify  Confonnance. 
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[A  Modular  Open  Systems  Approach  (MOSA)  to  Acquisition,  OSJTF] 

“National  Security  Systems  (NSS)”  are  any  telecommunications  or  information  systems 
operated  by  DoD  and  the  function,  operation,  or  use  of  which  involves  intelligence 
activities;  cryptologic  activities  related  to  national  security;  the  command  and  control  of 
military  forces;  equipment  that  is  an  integral  part  of  a  weapons  system;  or  criticality  to 
the  direct  fulfillment  of  military  or  intelligence  missions,  which  does  not  include 
procurement  of  automatic  data  processing  equipment  (ADPE)  or  services  to  be  used  for 
routine  administrative  and  business  applications  (including  payroll,  finance,  logistics,  and 
personnel  management  applications).  (CJSCI  3170.01G) 

“Naval  Open  Architecture  (NOA)”  is  the  confluence  of  business  and  technical 
practices  yielding  modular,  interoperable  systems  that  adhere  to  open  standards  with 
published  interfaces.  This  approach  significantly  increases  opportunities  for  innovation 
and  competition,  enables  reuse  of  components,  facilitates  rapid  technology  insertion,  and 
reduces  maintenance  constraints.  NOA  delivers  increased  warfighting  capabilities  in  a 
shorter  time  at  reduced  cost.  [RhumbLines,  December  12,  2006,  Naval  Office  of 
Information] 

“Open  Architecture”  means  a  type  of  architecture  whose  specifications  are  made  public 
by  its  designers  which  allows  users  to  make  modifications  to  various  components. 
[ITtoolbox], 

Note:  “Openness”  can  be  thought  of  in  degrees,  based  on  the  level  and  scope  of 
the  infonnation  provided  (for  example,  both  internal  and  external  information  on 
interfaces)  and  its  availability  to  third  parties  (e.g.  either  to  a  select  few  or  to  a 
broad  range  of  potential  component  providers). 

“Open  Source  Software”  is  computer  software  for  which  the  source  code  and  certain 
other  rights  normally  reserved  for  copyright  holders  are  provided  under  a  software  license 
that  meets  the  Open  Source  Definition  or  that  is  in  the  public  domain.  This  permits  users 
to  use,  change,  and  improve  the  software,  and  to  redistribute  it  in  modified  or  unmodified 
forms.  [Wikipedia.  Since  different  organizations  define  OSS  differently,  we  strongly 
urge  readers  to  also  refer  to  the  more  complex  definition  developed  by  the  Open  Source 
Initiative  (http://www.opensource.org)  and  other  organizations  such  as  the  Free  Software 
Foundation  (http://www.fsf.org)] 

“Open  Standards”  means  widely  accepted  and  supported  standards  set  by  recognized 
standards  organizations  or  the  marketplace.  These  standards  support  interoperability, 
portability,  and  scalability  and  are  equally  available  to  the  general  public  at  no  cost  or 
with  a  moderate  license  fee.  [Glossary  of  Defense  Acquisition  Acronyms  &  Terms,  13th 
Edition,  Nov.  2009\ 

“Open  System”  means  a  system  that  employs  modular  design  tenets,  uses  widely 
supported  and  consensus  based  standards  for  its  key  interfaces,  and  is  subject  to 
validation  and  verification  tests  to  ensure  the  openness  of  its  key  interfaces.  [A  Modular 
Open  Systems  Approach  (MOSA)  to  Acquisition,  OSJTF] 
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“Open  System  Architecture”  is  a  system  that  employs  modular  design,  uses  widely 
supported  and  consensus  based  standards  for  its  key  interfaces,  and  has  been  subjected  to 
successful  validation  and  verification  tests  to  ensure  the  openness  of  its  key  interfaces.  [A 
Modular  Open  Systems  Approach  (MOSA)  to  Acquisition,  OSJTF] 

“Open  Systems  Approach”  means  an  integrated  business  and  technical  strategy  that 
employs  a  modular  design  and,  where  appropriate,  defines  key  interfaces  using  widely 
supported,  consensus-based  standards  that  are  published  and  maintained  by  a  recognized 
industry  standards  organization.  [A  Modular  Open  Systems  Approach  (MOSA)  to 
Acquisition,  OSJTF] 

“Peer  Review”  (as  used  in  connection  with  Naval  Open  Architecture)  is  a  refereed,  open 
process  used  to  assess  technical  approaches  proposed  by  or  being  used  by  vendors.  There 
are  two  general  types  of  peer  reviews.  The  first  is  a  Government  Peer  Review  that 
includes  representation  from  government  activities  such  as  System  Commands,  PEOs  and 
Program  offices.  The  second  type  is  the  contractor  Peer  Review  that  includes  contractors 
as  participants.  Contractor  participants  should  be  drawn  from  a  cross  section  of  the 
broader  community  of  interest  with  academia  and  private  sector  entities  (including  large 
business,  small  business  and  non-traditional  DoD  contractors)  such  that  the  membership 
(taken  as  a  whole)  is  unbiased  and  impartial.  An  ‘independent  peer  review’  is  one  where 
the  membership  includes  individuals  from  outside  the  program  being  reviewed. 
Membership  is  structured  to  achieve  a  balanced  perspective  in  which  no  one  organization 
is  numerically  dominant.  Consensus  is  a  goal,  but  the  Peer  Review  Group’s  findings  or 
recommendations  to  the  decision  maker  normally  consist  of  a  majority  opinion  and  a 
documented  dissenting  opinion  if  the  minority  chooses  to  formalize  its  concerns.  This 
assessment  process  normally  results  in  findings  or  recommendations  presented  to  the 
decision  maker  with  the  authority  and  responsibility  to  select  or  make  the  final  course  of 
action  or  decision.. 

“Performance-based  Logistics”  is  the  preferred  sustainment  strategy  for  weapon  system 
product  support  that  employs  the  purchase  of  support  as  an  integrated,  affordable 
performance  package  designed  to  optimize  system  readiness.  PBL  meets  perfonnance 
goals  for  a  weapon  system  through  a  support  structure  based  on  long-term  performance 
agreements  with  clear  lines  of  authority  and  responsibility.  DoDI  5000.02  introduced  the 
tenn  “Product-Based  Life  Cycle  Product  Support”  as  the  latest  evolution  of  Performance- 
Based  Logistics  and  stated  that  both  tenns  can  be  referred  to  as  “PBL.”  [DAU  Glossary 
of  Defense  Acquisition  Acronyms  and  Terms,  13th  Edition ] 

“Portability”  is  a  characteristic  a  software  system  or  program  that  deals  with  the  ease 
with  which  the  software  can  be  modified  to  operate  in  an  execution  environment  other 
than  that  for  which  it  was  specifically  designed.  Execution  environments  include 
operating  systems,  middleware,  hardware,  and  environmental  interfaces.  If  minimal 
changes  to  the  software  are  required,  then  the  software  is  considered  to  be  highly 
portable.  If  no  changes  are  required,  then  the  term  is  not  applicable. 
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“Practical  application”  means  to  manufacture  in  the  case  of  a  composition  or  product, 
to  practice  in  the  case  of  a  process  or  method,  or  to  operate  in  the  case  of  a  machine  or 
system;  and,  in  each  case,  under  such  conditions  as  to  establish  that  the  invention  is  being 
utilized  and  that  its  benefits  are,  to  the  extent  pennitted  by  law  or  Government 
regulations,  available  to  the  public  on  reasonable  terms.  [FAR  Section  52.227-12 ] 

“Process”  is  a  set  of  interrelated  activities  designed  to  accomplish  a  specified  goal. 
IEEE/EIA  Std.  12207/1997  Table  1  lists  all  12207  processes  and  their  associated 
activities.  For  example  Development  is  a  process.  Within  Development  there  are  thirteen 
activities  as  shown  in  Table  1.  One  of  these  activities  is  Software  Coding  and  Testing 
which  has  five  tasks.  [IEEE/EIA  Std.  12207/1997] 

“Reliability”  is  directed  toward  assuring  that  a  given  design  attains  the  longest  possible 
continued  operation  [i.e.,  high  Mean  Time  Between  Failures  (MTBF)  and  low  Mean 
Time  To  Repair  (MTTR)]  and  operating  life.  (Defense  Acquisition  University) 

“Reconfigurability”  means  that  a  system  or  a  service’s  state  and  behavior  can  be 
dynamically  modified  during  its  operation.  [University  of  Athens,  Communications 
Networks  Laboratory] 

“Reusability”  is  the  degree  to  which  a  software  module  or  other  work  product  can  be 
used  in  more  than  one  computing  program  or  software  system  [IEEE] 

“Restricted  Rights”  (RR)  applies  only  to  noncommercial  software  and  means,  in  part, 
the  Government’s  rights  to  use  the  computer  program; 

•  With  one  computer  at  a  time; 

•  To  transfer  the  program  to  another  computer  subject  to  restrictions; 

•  To  make  minimum  copies  for  safekeeping,  modification  or  backup; 

•  To  modify  the  software  for  the  above  purposes; 

•  To  permit  contractors  or  subcontractors  performing  services  in  support  of  this 
or  a  related  contract  to  use  the  software  to  diagnose  and  correct  deficiencies  or 
to  respond  to  urgent  tactical  situations,  subject  to  subject  to  non-disclosure 
and  restrictions  against  reverse  engineering  and  other  restrictions. 

•  To  permit  contractors  or  subcontractors  performing  emergency  repairs  or 
overhaul  of  items  or  components  of  items  procured  under  this  or  a  related 
contract  to  use  the  computer  software  when  necessary  to  perform  the  repairs 
or  overhaul  or  to  modify  the  software  to  reflect  the  repairs/overhaul,  subject  to 
non-disclosure  and  restrictions  against  reverse  engineering. 

[DFARS  §252. 22  7-  701 4(a)  (1 4)\ 

“Scalability”  is  the  capability  of  a  piece  of  hardware  or  software  to  easily  expand  to 
meet  future  computing  needs.  [Microsoft  TechNet] 

“Small  business  firms”  means  a  small  business  concern  as  defined  at  section  2  of 
Pub.  L.  85-536  (15  U.S.C.  632)  and  implementing  regulations  of  the  Administrator  of  the 
Small  Business  Administration.  [FAR  Section  52.227-12 ] 
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“Software  Architecture”  of  a  program  or  computing  system  is  the  structure  or  structures 
of  the  system,  which  comprise  software  elements,  the  externally  visible  properties  of 
these  elements,  and  the  relationships  among  them.  [IEEE] 

“Software  Reuse”  is  the  process  of  implementing  or  updating  software  systems  using 
existing  software  assets.  [DA  U  Glossary  of  Defense  Acquisition  Acronyms  and  Terms, 
13th  Edition ]  The  DoD  5000.1  Acquisition  Guidebook  states  that  the  “program  manager 
should  base  software  systems  development  on  robust  systems  engineering  principles.  The 
following  best  practice[]  for  software  systems  also  apply  in  general  to  any  system.  ... 
Identifying  and  exploiting,  where  practicable,  Government  and  commercial  software 
reuse  opportunities  before  developing  new  software.”  Potential  software  assets  include; 

1 .  Computer  Software  -  Computer  programs,  procedures,  and  possibly  associated 
documentation  and  data,  pertaining  to  the  operation  of  a  computer  system. 

2.  Software  Development  Plan  (SDP)  -  A  management  plan  usually  generated  by 
the  developer  describing  in  detail  the  processes,  activities,  and  tasks  to  be 
performed  to  accomplish  the  software  development  effort. 

3.  Computer  Software  Documentation  -  Technical  Data  (TD)  infonnation, 
including  computer  listings  and  printouts,  that  documents  the  requirements, 
design,  or  details  of  computer  software,  explains  the  capabilities  and  limitations 
of  the  software,  or  provides  operation  instructions  for  using  or  supporting 
computer  software  during  the  software's  operational  life. 

4.  Software  Product  Specification  -  Detailed  design  and  description  of  Software 
Items  (Sis)  comprising  the  product  baseline.  Analogous  to  the  Item  Detail 
Specification  of  a  hardware  Configuration  Item  (Cl)  in  the  product  baseline  of  a 
hardware  system. 

5.  Software  Requirement  Specification  (SRS)  -  A  description  of  the  requirements 
(behaviors,  functions,  perfonnance,  design  constraints  and  attributes)  allocated  to 
a  specific  Software  Configuration  Item  (SCI).  Often  accompanied  by  an  Interface 
Requirements  Specification  (IRS)  for  that  SCI. 

6.  Software  Specification  Review  (SSR)  -  A  life  cycle  review  of  the  requirements 
specified  for  one  or  more  Software  Configuration  Items  (SCIs)  to  determine 
whether  they  form  an  adequate  basis  for  proceeding  into  preliminary  design  of  the 
reviewed  item.  See  Software  Requirement  Specification  (SRS)  and  Interface 
Requirement  Specification  (IRS). 

7.  Interface  Requirement  Specification  (IRS)  -  A  type  of  Item  Performance 
Specification  that  defines  the  required  software  interfaces  for  a  given  Software 
Item  (SI)  in  the  allocated  baseline,  the  requirements  for  which  are  described  by  a 
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Software  Requirements  Specification  (SRS).  The  IRS  is  frequently  combined  with 
the  SRS. 

8.  Computer  Software  Component  (CSC)  -  Under  some  software  development 
standards,  a  functional  or  logically  distinct  part  of  a  Computer  Software 
Configuration  Item  (CSCI),  or  Software  Configuration  Item  (SCI) 

9.  Software  Item  (SI)  -  An  aggregation  of  software,  such  as  a  computer  program  or 
database  that  satisfies  an  end  use  function  and  is  designated  for  purposes  of 
specification,  qualification,  testing,  interfacing,  Configuration  Management  (CM), 
or  other  purposes.  An  SI  is  made  up  of  Computer  Software  Units  (CSUs). 

10.  Software  Resources  Data  Report  (SRDR)  -  SRDR  is  intended  to  improve  the 
ability  of  the  DoD  to  estimate  the  costs  of  software  intensive  programs.  SRDR 
reporting  is  required  by  DoD  Instruction  5000.2,  Enclosure  3,  for  major  contracts 
and  sub-contracts  (regardless  of  contract  type)  associated  with  high-cost  software 
elements  within  Acquisition  Category  I  and  Acquisition  Category  IA  programs. 
Data  collected  from  applicable  contracts  include  type  and  size  of  the  software 
application(s),  schedule,  and  labor  resources  needed  for  the  software 
development. 

1 1 .  Analysis  of  Alternatives  -  The  evaluation  of  the  perfonnance,  operational 
effectiveness,  operational  suitability,  and  estimated  costs  of  alternative  systems  to 
meet  a  mission  capability.  The  analysis  assesses  the  advantages  and  disadvantages 
of  alternatives  being  considered  to  satisfy  capabilities,  including  the  sensitivity  of 
each  alternative  to  possible  changes  in  key  assumptions  or  variables.  The  AoA  is 
normally  conducted  during  the  Concept  Refinement  phase  of  the  Defense 
Acquisition  Framework  and  the  results  of  the  AoA  align  with  the  system  concept 
contained  in  the  Initial  Capabilities  Document  (ICD)  approved  prior  to  Milestone 
A. 

12.  Initial  Capabilities  Document  -  Documents  the  need  for  a  materiel  approach,  or 
an  approach  that  is  a  combination  of  materiel  and  non-materiel,  to  satisfy  specific 
capability  gap(s).  The  ICD  defines  the  gap  in  terms  of  the  functional  area;  the 
relevant  range  of  military  operations;  desired  effects;  time  and  Doctrine, 
Organization,  Training,  Materiel,  Leadership  and  Education,  Personnel,  and 
Facilities  (DOTMLPF);  and  policy  implications  and  constraints.  The  outcome  of 
an  ICD  could  be  one  or  more  DOTMLPF  Change  Recommendations  (DCRs)  or 
Capability  Development  Documents. 

13.  Systems  Engineering  Plan  -  A  description  of  the  program’s  overall  technical 
approach  including  processes,  resources,  metrics,  applicable  perfonnance 
incentives,  and  the  timing,  conduct,  and  success  criteria  of  technical  reviews. 

14.  Test  and  Evaluation  Master  Plan  -  Documents  the  overall  structure  and 
objectives  of  the  Test  and  Evaluation  (T&E)  program.  It  provides  a  framework 
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within  which  to  generate  detailed  T&E  plans  and  it  documents  schedule  and 
resource  implications  associated  with  the  T&E  program.  The  TEMP  identifies  the 
necessary  Developmental  Test  and  Evaluation  (DT&E),  Operational  Test  and 
Evaluation  (OT&E),  and  Live  Fire  Test  and  Evaluation  (LFT&E)  activities.  It 
relates  program  schedule,  test  management  strategy  and  structure,  and  required 
resources  to;  Critical  Operational  Issues  (COIs),  Critical  Technical  Parameters 
(CTPs),  objectives  and  thresholds  documented  in  the  Capability  Development 
Document  (CDD),  evaluation  criteria,  and  milestone  decision  points.  For  multi¬ 
service  or  joint  programs,  a  single  integrated  TEMP  is  required.  Component- 
unique  content  requirements,  particularly  evaluation  criteria  associated  with  COIs, 
can  be  addressed  in  a  component-prepared  annex  to  the  basic  TEMP. 

15.  Capability  Development  Document  -  A  document  that  captures  the  information 
necessary  to  develop  a  proposed  program(s),  preferably  using  an  evolutionary 
acquisition  strategy.  The  CDD  outlines  an  affordable  increment  of  militarily 
useful,  logistically  supportable,  and  technically  mature  capability.  The  CDD 
supports  a  Milestone  B  decision  review. 

16.  Acquisition  Program  Baseline  -  Prescribes  the  key  cost,  schedule,  and 
performance  parameters,  each  with  an  objective  and  threshold,  to  which  the 
program  will  be  executed  in  the  phase  succeeding  the  milestone  for  which  the 
APB  was  developed.  The  APB  constitutes  an  agreement  between  the  program 
manager,  OPNAV  sponsor,  and  milestone  decision  authority,  and  the  breaching  of 
any  one  parameter  threshold  will  necessitate  a  re-baselining  with  a  new  APB 
agreed  to  by  those  three  parties. 

17.  Training  Plan  -  Outlines  the  level  of  learning  required  to  adequately  perform  the 
responsibilities  designated  to  the  function  and  accomplish  the  mission  assigned  to 
the  system. 

[DoD  5000.1  Acquisition  Guidebook ] 

“System  Architecture”  is  the  composite  of  the  design  architectures  for  products  and 
their  life  cycle  processes.  [IEEE  1220-1998] 

“Subject  Invention”  means  any  invention  of  the  contractor  conceived  or  first  actually 
reduced  to  practice  in  the  perfonnance  of  work  under  this  contract;  provided,  that  in  the 
case  of  a  variety  of  plant,  the  date  of  determination  (as  defined  in  section  41(d)  of  the 
Plant  Variety  Protection  Act,  7  U.S.C.  2401(d))  must  also  occur  during  the  period  of 
contract  perfonnance.  [FAR  Section  52.227-12 ] 

“Tasks”  are  specific  actions  perfonned  to  accomplish  an  activity.  The  way  that  each  task 
is  performed,  such  as  testing,  is  called  the  technique  or  method.  [IEEE/EIA  Std. 
12207/1997] 

“Technology  Insertion”  is  increasing  a  system’s  or  product’s  Warfighting  operational 
capability  by  integrating  new  capabilities  or  upgrading  the  system’s  current  capabilities 
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with  up-to-date  and  more  capable  COTS  or  custom  technologies.  [Software  Engineering 
Institute ] 

“Upgradeability”  is  the  ease  with  which  a  system  or  component  can  be  modified  to  take 
advantage  of  new  software  or  hardware  technologies.  [ Software  Engineering  Institute ] 

“Unlimited  rights”  (UL)  means  rights  to  use,  modify,  reproduce,  perform,  display, 
release,  or  disclose  intellectual  property  and  technical  data  in  whole  or  in  part,  in  any 
manner,  and  for  any  purpose  whatsoever,  and  to  have  or  authorize  others  to  do  so.  [ DAU 
Glossary  of  Defense  Acquisition  Acronyms  and  Terms,  13th  Edition ] 
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